Who is responsible for checking for NullReferenceExceptions?

Question

For example if you pass a car into a sub that makes use of a car who should be checking for null references?

Should I even bother wrapping this code in the below if statement? It seems quite redundant, obviously I could have given a better example because I can't catch the exception and handle it in any way.

Or should I just let the exception bubble up to the caller?

For example:

Public Sub CarService(ByVal car As ICar)
    If car IsNot Nothing Then
        'do logic here 
    Else : Throw New ArgumentNullException
    End If
End Sub

Side note: It should be a [ArgumentNullException](http://msdn.microsoft.com/en-us/library/27426hcy.aspx) and personally I don't wrap the whole method into the `if`; I just check for `null`/`Nothing` and throw or proceed. — Filburt, Nov 09 '12 at 07:52

score 4 · Accepted Answer · edited May 23 '17 at 11:48

Throwing a NullReferenceException yourself is actually pointless. As this is

the same exception that the CLR would raise (at least when you access the same reference that you manually check for null) and
is discouraged anyway. See Remarks here. For a related discussion see Is it necessary to throw a NullReferenceException from an extension method?.

You should however, arguably at least for the public API surface, check for null references and throw an ArgumentNullException.

Public Sub CarService(ByVal car As ICar)
    If car Is Nothing Then
        Throw New ArgumentNullException("car")
    End If
    ' do logic here
End Sub

Or look into Code Contracts.

score 1 · Answer 2 · answered Nov 09 '12 at 07:48

I think it's a good idea since you prevent the code to be unpredictable. Since the exception depends on the following code and can change with it. With your code you know where and what exception can be thrown.

The only thing you should think about is what exception you should use or even create a own one. Since NullReference seems a little bit misplaced.

score 1 · Answer 3 · answered Nov 09 '12 at 07:49

I guess it depends on the scenario. There are cases when null is a valid value to pass to a method. If it's not then you need to weigh how much logic would occur before the code would reach the null object. If nothing significant happens until that point then you can simply let it bubble up. If you do make significant operations before using that object then it's worth checking it right when you enter the method. Also if you have more than one object then the caller would not know which one caused the issue so you might throw the exception yourself, adding a proper error message.

score 1 · Answer 4 · answered Nov 09 '12 at 07:49

Its up to you.

If NULLs are a part of your logic, then handle it inside your CarService method. For eg., in your code a NULL car may mean its an unknown car in which case you will have to write the logic for it.

You should throw the exception if you are not supposed to pass a NULL. That way the edge case will be handled at the caller side. For instance, if your code does something like this:

Public Sub CarService(ByVal car As ICar)
    car.ToString();
End Sub

In such cases explicitly throwing error makes sense which will be consistent throughout framework.

score 1 · Answer 5 · answered Nov 09 '12 at 08:02

In my opininion throwing the NullReferenceException yourself is nonsense (CLR will do it for you). But on the other hand throwing the ArgumentNullException is a good practice for me. If error occurs, you know exactly where the problem is and which parameter cannot be null. To save time writting such ever-repating code I use macros in ReSharper (no problem to get under 2 seconds).

Who is responsible for checking for NullReferenceExceptions?

5 Answers5