http://qconlondon.com/london-2009/presentation/Null+References:+The+Billion+Dollar+Mistake

I’m not sure if I agree but I can see the merit in your argument. Do you also use SAL annotation to help verify that you code is not capable of passing null into your methods?

Thanks Chuck, I appreciate the feedback. I think you get my point exactly.

Schmuli,

To answer you question, in my opinion the check belongs in the public facing methods. Now, there is a difference between public methods and public facing methods. If you have a class that you are using internally with public methods, I would lean towards practicing the reduction of use of nulls and checking there. But if you truly have an external API beyond your control, you need to not only check the input for nulls, but treat the input as malicious, and do whatever protection is needed. The place to do it is at the point of entrance.

Timely article as I had just read Robert Martin say the same thing in his book “Clean Code” (which all developers should read).

Both you and Bob did not say “No Null” (like the popular “No SQL”). I think that, through the comments, it has been clarified that we are talking about the objects created in code. Since a database is external, you probably should do some null checks (especially if you pass datasets around).

Of course, like anything, this will work only as well as your testing goes, especially the end-to-end testings. If Bob didn’t follow the standards and passed in an uninitialized and that code makes it to production…the response will most likely be a null object check and Bob will probably never hear about it (unless of course, we decide to enforce the programming standards).

Enjoyed the article and will bring it up to my group today.

Chuck

I think you are missing the point.

What I am suggesting is transferring the energy used to check for null in your codebase to preventing the passing of null into methods.

You are right you have to check for null somewhere, but in many instances you can “check for null” by writing your code in a such as way that null is not a possibility at all.

It is very hard to show examples that are not very long.

But the core of what I am saying here is that effort used to check for null is better spent preventing null.

The return on this investment is less code and better design. Null tends to be a crutch. Trying to prevent null usually leads to a better design.

There are public API points where you need to check for null, but once you pass those points, internally you can prevent null from making it further into your codebase.

Throwing ArgumentNullExceptions is a fairly popular answer, but the problem with that is it is a runtime prevention, which is not a prevention at all. To the end-user a null reference exception is no different than an ArgumentNullException. Either way they end up having the application crash. (Unless you are going to catch ArgumentNullExceptions everywhere.)

If you tend toward immuatable objects, you eliminate the possibility of any of their fields being null.

#1
I’ve got the ‘don’t trust the caller’ philosophy engrained too deeply in me.

#2
There’s no point in making an expensive call to a database, or Active Directory, when I know up front (by checking for null) that the call will fail.

#3
If I use that null value in the calls I make, say, to my Oracle database, I’m going to generate OracleExceptions that I either need to handle, or let propagate to the caller.

If I have to handle them, I’d rather test before-hand, so that I know an OracleException means a true issue calling the database.

Propagating them to the caller breaks encapsulation. Now the caller has to handle OracleExceptions, and knows how I’m handling my back end. And if I switch to SQL Server? Should the caller have to re-write all of his code to handle SQL Server exceptions?

Throwing an ArgumentNullException clearly tells the caller he can’t pass null for the Username.

#4
Contrary to what the author claims, I DO know what a null value means. If I’m concatenating three strings, and one is null, I’ve decided up front that either (a) a null value can’t be concatenated, or (b) a null value translates to an empty string, which is clearly documented in my XML documentation, and therefore in the help text in the Object Browser.

I will *always* know what a null value means, because as the designer of the method, I’ve decided up front what it means. And what I say it means is law.

#5
You have to be anal retentive, SOMEwhere… the argument that you aren’t checking for null in every method doesn’t hold water – you either have to check for null in the callee, or check for null in the caller. What’s the difference? It’s not acceptable in either one to only check some of the time.

I mean no disrespect, but this is one of the worst pieces of advice I’ve seen offered in a long time, and all it comes across as is laziness.

How about the three null checks you are not doing in “ds.Tables[0].Rows[0]["JOLInd"].ToString()”? In fact, the six null checks you’re not doing, because you copy pasted that compound expression so you have it two times. The world is (almost always) more complex than you initially think…

I prefer to check all arguments of public API methods and raising ArgumentExceptions on those as appropriate and then try to use (and check for) as little nulls as possible, for instance by using sentinels where appropriate. Any problems regarding nulls should be found in unit test code or by software testers (through the applications top level exception handling).

checking null is really a bad practice?

What if you forget to put the check in for .IsValid? If you return a list and 90% of the time you’re dealing with 1 expected result you’re going to have to remember to check if the list is empty or not because [0] will net you index out of range exceptions, and similar with Linq’s “First()” unless you use “FirstOrDefault()” in which case you’re exactly back where you started. I fact, I find I need to deal with #null more frequently with Linq since I often find myself using functions like FirstOrDefault().

Personally I favour to check required arguments and throw ArgumentNullExceptions with the parameter name. These are exceptions, they’re going to need to be raised, recorded, and fixed, or at minimum, presented to the user in a meaningful way… No sugar-coating required. Though I definitely agree that code should always avoid using/returning #null wherever possible. #Null is here to stay, so just be sure to guard against nothing when you expect something.