7

I'm cleaning up some legacy code and I have found methods which explicitly throw a NullReferenceException (e.g.: when checking if some properties of a class are null, or checking configuration). As this type of exception is thrown by CLR in case of a null reference, this seems like a very poor choice of an exception for an application to throw explicitly.

My question is - are there any reasons for which a NullReferenceException would be a good choice for an exception to throw explicitly from code?

Stephen Kennedy
  • 20,585
  • 22
  • 95
  • 108
Marcin Seredynski
  • 7,057
  • 3
  • 22
  • 29
  • probably not, we check parameters and sometimes we throw ArgumentNullException but this is good for arguments and parameters, for properties not sure... – Davide Piras Oct 19 '11 at 13:09

6 Answers6

9

The documentation for NullReferenceException implies that you shouldn't throw it from an application:

Note that applications throw the ArgumentNullException exception rather than the NullReferenceException exception discussed here.

And I am sure I've seen guidance elsewhere (can't find any at the moment-> it is here https://learn.microsoft.com/en-us/dotnet/standard/design-guidelines/using-standard-exception-types) that you should avoid throwing exception types that the runtime throws (although I'm about to link to something which shows the runtime throwing an "application" exception)

If you're checking properties within a method, before proceeding, it sounds like you might want to replace them with InvalidOperationException:

InvalidOperationException is used in cases when the failure to invoke a method is caused by reasons other than invalid arguments.

Being in the incorrect state for the method call sounds like it fits this definition.

Mohd Amir
  • 3
  • 3
Damien_The_Unbeliever
  • 234,701
  • 27
  • 340
  • 448
5

No, there is no reason to throw a NullReferenceException.

You always have some more information about the reason for the error, so you should throw an exception that conveys that information.

If you for example get a null reference as an argument where it's not allowed, you would throw an ArgumentException or ArgumentNullException instead.

Guffa
  • 687,336
  • 108
  • 737
  • 1,005
2

MSDN says this:

Note that applications throw the ArgumentNullException exception rather than the NullReferenceException exception discussed here.

So the answer to your question is probably "no".

M4N
  • 94,805
  • 45
  • 217
  • 260
2

No, NullReferenceException should only be thrown by the framework itself. ArgumentNullException or InvalidOperationException are valid alternatives.

devdigital
  • 34,151
  • 9
  • 98
  • 120
  • 1
    Shouldn't use [NotSupportedException](http://msdn.microsoft.com/en-us/library/system.notsupportedexception.aspx) in this case: "For scenarios where it is sometimes possible for the object to perform the requested operation, and the object state determines whether the operation can be performed, see InvalidOperationException. – Damien_The_Unbeliever Oct 19 '11 at 13:16
1

I'm assuming that if the code didn't check you would get a NullReferenceException(NRE) any way so no. However I see no issue with having a application message that better explains the calling mechanism of the particular function with an inner exception type of NRE or ArgumentExecption as that is underling issue that is causing the problem.

rerun
  • 25,014
  • 6
  • 48
  • 78
0

I can invision senarios where it would make sense to throw it explicitly. The first one that comes to mind is checking properties before a lot of other processing is done before the exception would be encountered by the CLR.

ShaneBlake
  • 11,056
  • 2
  • 26
  • 43