What type of exception

Question

What type of exception would you choose from the readonly property when the object that is used to return the value is null

public class TestClass { SomeObject obj; public string NameOfObject { get { if(obj == null) { // what exception type to throw here } return obj.Name; } } 

Answer 1

An InvalidOperationException is what I will use in this case, since access to the property is not valid for the current state of the object.

According to the MSDN documentation:
"An exception that is thrown when a method call is not valid for the current state of the object."
also:
"An InvalidOperationException is used in cases where a failure to call a method was caused by reasons other than invalid arguments."

In this case, obj is not an argument, so I would skip "InvalidOperationException"

The reason I would not throw a NullReferenceException: If you have not added any special code, it is an exception that ".Net" will throw, so why add redundant code?

Answer 2

I would InvalidOperationException .

I only throw an ArgumentNullException if the parameters of the methods are zero.

If the methods parameter is in an invalid state, I throw an ArgumentException .

Answer 3

You should not throw a NullReferenceException. It is reserved for situations where a null object is dereferenced. In this case, if you were to throw a NullReference, you can just leave the null check and let the framework drop it for you when you try to access the obj name.

I would throw an InvalidOperationException .

Answer 4

Unless you say somewhere that this property will never be null, why do you need to throw an exception?

Having said that, if you guarantee it, I would InvalidOperationException .

InvalidOperationException is

An exception is thrown when a method call is invalid for the current state of an object.

Answer 5

Everyone touched on the obvious, so here is another option.

If your class needs to be initialized in any way (your SomeObject needs to be installed at some point), consider implementing ISupportInitialize . This tells the users of your class that it is not in the correct state until EndInit() called. Unfortunately, there is no existing generic NotInitializedException that you can use (some of them are specific to specific namespaces), so I would suggest linking your interface implementation to throwing such an exception.

First, users must call BeginInit() , then configure the instance, and then call EndInit() . When calling EndInit() check the status of your instance. If it is incorrectly initialized, you can raise an InvalidOperationException. If users try to use your instance before initialization, you should throw a NotInitializedException.

It’s a bit bigger, but the advantage is that you create a wider “pit of success” for your users, ensuring that they use your classes correctly, quickly and early, and by the very definition of your type (the interface is pretty clear that you expect). It also gives you more “room”, so to speak, to document how your class should be used.

Answer 6

I would InvalidOperationException , but only if: - obj is legal null , and the responsibility lies with the user, or - it is not legal for obj be null in the first place (i.e. obj != null is a class invariant)

If none of the above cases is (i.e., obj is null ), and the user code is clearly not required to verify this before using the property), then I would not quit at all, but rather return null .

Answer 7

I would revise the design so that this state could not exist in the first place, that is, obj is null. Typically, from an API point of view, you should be able to call a getter in good faith so that it does not explode as a result of the object being in an unknown state.

For example, why not "SomeObject obj" as a constructor parameter and use argument checking at the build point. This ensures that the state of "obj" is always correct, i.e. It doesn't matter null after building.

There are many templates that can be used to ensure the correct state of an object when it becomes available to the user.

Answer 8

Looking at the code you provide and not knowing anything about your design assumptions, I would say that you should not test obj == null at all and let the framework throw a NullReferenceException . So why do you need this test? One of the reasons I might think is that you want to have a more meaningful error message for debugging, but then you should use Debug.Assert(obj != null, "Your message here") .