What exception should I throw for an unexpected null value?

Question

I've been a .NET developer for over a decade so here's a shameful question I've never known the answer to. I get it--if an argument is null, I can throw an ArgumentNullException. A NullReferenceException will be thrown if I try to dereference a null value.

But what if I have code like the following:

var someVitalObject = someServiceReference.GetVitalObject();

if (someVitalObject == null)
{
  throw new IDontKnowWhatException(); // what exception should I throw here?
}

Now, this isn't necessarily a problem with the service for which an exception should have been thrown earlier.

Is this being null an error in the execution flow? Will this cause your app to terminate? Perhaps more context will help us understand the problem better. — Yuval Itzchakov, Dec 08 '15 at 18:59
So is `GetVitalObject()` breaking its contract, or is it valid for that to return null, but just not in this case? — Jon Skeet, Dec 08 '15 at 18:59
Does the API make some guarantee about whether the object can be null or not? If so it might be more of an assertion failure (use Trace.Assert). Otherwise a custom exception like VitalObjectNotFoundException would be appropriate. — Mike Zboray, Dec 08 '15 at 19:01
In my case, to make it simpler, pretend that I'm checking the state of a cache to see if it has the "vital object" stored. It should by then, and if it doesn't then that's a problem. — vargonian, Dec 09 '15 at 21:52

score 11 · Answer 1 · answered Dec 08 '15 at 18:58

11

It's hard to say without seeing more context, but perhaps System.InvalidOperationException?

The exception that is thrown when a method call is invalid for the object's current state.

answered Dec 08 '15 at 18:58

cbr

12,563
3
38
63

score 7 · Answer 2 · answered Dec 08 '15 at 19:07

7

I typically use ArgumentNullException for objects passed into a function. Anything else null related I use InvalidOperationException. In specialized cases I'll create a custom exception if it makes sense to.

answered Dec 08 '15 at 19:07

Gwendolyn Goetz

305
1
2
8

Mark · Answer 3 · 2015-12-08T22:21:46.123

1

I would only use System.ArgumentNullException when directly checking a method parameter, not when validating the result of some call.

The type of exception I throw depends greatly on the context. But in this case I would probably go for a custom exception like:

public class VitalObjectNotAcquiredException : Exception { ... }

edited Dec 08 '15 at 22:21

answered Dec 08 '15 at 19:01

Mark

1,360
1
8
14

Dmitry · Answer 4 · 2015-12-08T19:45:46.507

0

Consider to create your own Exception class inherited from the ApplicationException or from the Exception:

public sealed class MyException : Exception
{
    ...
}

Thus you will be able to control what kind of information to store in it.

edited Dec 08 '15 at 19:45

answered Dec 08 '15 at 18:59

Dmitry

13,797
6
32
48

In general inheriting from `ApplicationException` is considered a bad practice http://stackoverflow.com/questions/52753/should-i-derive-custom-exceptions-from-exception-or-applicationexception-in-net – juharr Dec 08 '15 at 19:22
@juharr Is useless == bad practice? [ApplicationException considered useless](http://blogs.msdn.com/b/kcwalina/archive/2006/06/23/644822.aspx): *ApplicationException is not considered harmful, just useless.* – Dmitry Dec 08 '15 at 19:44
I guess I was thinking of catching `ApplicationException` as a bad practice. – juharr Dec 08 '15 at 20:29

score 0 · Answer 5 · answered Dec 08 '15 at 20:36

Personnally, I'd choose according to the GetVitalObject method contract. If this method should return a not null object I'd change it so it throws an exception in this case.

If you don't have control over the method or if returning a null value is correct (but not in your context) i'd go with a custom exception as Mark and Dmitry already said.

What exception should I throw for an unexpected null value?

5 Answers5