Returning Nulls is Dishonest

I read an interesting blog post today by Andy Palmer. I thought it was a good point and a principle I am trying to encourage on the software projects I work on.

I agree that a method should not return null when it doesn’t have a return value. There will be a reason why a return did not happen. I agree that throwing exceptions is a good way to indicate a valid return object was not possible because of an error condition, but I also have plenty of cases in my current project where something requests some data and there can be a good reason for it not being available. In these cases I am encouraging people to build return classes to pass back the value returned or a reason why one couldn’t be. I feel while this obviously results in more code, there is nothing more irritating then a NullReferenceException being thrown when you know the reason the value is null because of an event that has already happened. I feel if I never purposely make a null occur in my software, then a) I never have to check for them, and b) when one occurs, I immediately know there is something unexpectedly wrong.

The post is here: http://andypalmer.com/2008/08/returning-null-considered-dishonest/

Advertisements
This entry was posted in Comment and tagged , . Bookmark the permalink.

3 Responses to Returning Nulls is Dishonest

  1. Jhessie Boy says:

    I agree. When you have a methods that have complex implementations in them, then it is a good practice to throw some exceptions rather to return NULL values.

  2. chendd says:

    nice to know you, and glad to find such a good article!

  3. Andy Palmer says:

    I’m not keen on the Maybe pattern because I end up with a similar amount of code as I would with the null checks. I still have to check whether I got the result I wanted, or fail in some way if I didn’t.
    If the bad result comes from a previous event that I knew about, I would generally handle it at that event, and halt the execution there, rather than say “Oh, here’s a result type, you didn’t get your result because the database connection wasn’t successful”
    I generally use Exceptions to halt the execution and say “nothing that you would have attempted from here makes any sense because “. I use it more in the Lisp condition sense than the pure Java/C# sense.

    The example that I used with Drink came from a coding Dojo I was running where we were designing a vending machine. We started off driving the interface from a code perspective, but because of the way that the error conditions resulted in an exception, Liz Keogh was able to whip up a Swing interface that drove the code from a Vending Machine gui perspective. The thing that I liked most about that was she was able to catch the Exceptions at the application level and display them on the message panel, without any additional code to generate the error messages.
    With NarrativeFixture, which runs in FitNesse, the exception trace gets displayed directly in the test results, and we use helpful exception names and messages to guide the developer to implement the structure required to get the test running correctly (much like Cucumber and JBehave give pending messages for undefined steps)
    I have also changed my Exception naming practices, such that now, if the error is caused by something outside of the user control (ie. the user asked something reasonable) then the code throws an Apology. For example, when asking for something from a map or database, but the key doesn’t resolve, then I would throw a ThingNotFoundApology.
    For things that the user has done wrong, whether by accident or design, then I would throw a Complaint. For example, if I ask for a single result, but the method finds multiple items, then throw a TooManyChoicesComplaint. That works really well.

    Having said all that, Exceptions aren’t my only way of working. Where a collection makes sense, I much prefer to return an empty collection, because anything that would have iterated over a collection can safely iterate over an empty collection with no ill effects (yay)

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s