Should I return null or throw an exception?

Question

I found questions here Should a retrieval method return 'null' or throw an exception when it can't produce the return value? and Should functions return null or an empty object?, but I think my case is quite different.

I'm writing an application that consists of a webservice and a client. The webservice is responsible to access data, and return data to the client. I design my app like this:

//webservice

try
{
   DataTable data = GetSomeData(parameter);
   return data
}
catch (OopsException ex)
{
   //write some log here
   return null; 
}

//client:

   DataTable data = CallGetSomeData(parameter);
   if(data == null) 
   {
      MessageBox.Show("Oops Exception!");
      return;
   }

Well, there is a rule of not returning null. I don't think that I should just rethrow an exception and let the client catch SoapException. What's your comment? Is there better approach to solve this problem?

Thank you.

Answer 1

In general i try to design my webservices in such way that they return a flag of some sort that indicates whether there was a technical/functional error or not. additionally i try to return a complex object for result not just a string, so that i can return things like:

result->Code = "MAINTENANCE" result->MaintenanceTill = "2010-10-29 14:00:00"

so for a webservice that should get me a list of dataEntities i will return something like:

<result>
    <result>
        <Code>OK</Code>
    </result>
    <functionalResult>
        <dataList>
            <dataEntity>A</dataEntity>
        </dataList>
    </functionalResult>
</result>

so every failure that can occur behind my webservice is hidden in a error result. the only exceptions that developers must care about while calling my webservice are the exceptions or errors that can occur before the webservice.

Answer 2

All the WebServices that I've used return objects, not simple data types. These objects usually contain a bool value named Success that lets you test very quickly whether or not to trust the data returned. In either event, I think any errors thrown should be untrappable (i.e. unintentional) and therefore signify a problem with the service itself.

Answer 3

In your case, an exception has already been thrown and handled in some manner in your web service.

Returning null there is a good idea because the client code can know that something errored out in your web service.

In the case of the client, I think the way you have it is good. I don't think there is a reason to throw another exception (even though you aren't in the web service anymore).

I say this, because, technically, nothing has caused an error in your client code. You are just getting bad data from the web service. This is just a matter of handling potentially bad input from an outside source.

Personally, as a rule of thumb, I shy away from throwing exceptions when I get bad data since the client code can't control that.

Just make sure you handle the data == null condition in such a way that it doesn't crash your client code.