Reputation: 2217

What type of exception to throw

What typeo of exception would you throw from a readonly property when the object that is being used to return value is null

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

Upvotes: 11

Answers (8)

Tim Lloyd

Reputation: 38444

I would revisit the design so that this state cannot exist in the first place i.e. obj is null. Generally from an API perspective you should be able to call a getter in good faith that it will not blow up as a result of the object being in an unknown state.

For example, why not have 'SomeObject obj' as a constructor parameter and use argument validation at the point of construction. This will ensure that the state of 'obj' is always correct i.e. non-null after construction.

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

Upvotes: 1

TomBot

Reputation: 1146

Looking at the code you provide and not knowing anything about your design assumptions I'd say that you should not test obj == null at all and let the framework throw a NullReferenceException. So why do you want this test? One reason I could think of 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").

Upvotes: 1

user1228

Reputation:

Everybody has covered the obvious, so here's another option.

If your class must be initialized in some manner (your SomeObject must be set at some point), consider implementing ISupportInitialize. This indicates to users of your class that it is not in a valid state prior to EndInit() being called. Unfortunately, there is no preexisting general NotInitializedException you can use (there are some but are specific to certain namespaces), so I would suggest pairing your implementation of the interface with the creation of such an exception.

Users must first call BeginInit(), then configure the instance, then call EndInit(). On the call to EndInit(), check the state of your instance. If it is not correctly intialized, you can throw an InvalidOperationException. If users attempt to use your instance prior to being initialized, you would throw your NotInitializedException.

Its a bit more work, but the advantage is that you are creating a wider "pit of success" for your users, ensuring they use your classes correctly by failing fast and early, and by the very definition of your type (the interface is pretty clear on what you expect). It also give you more "room", so to speak, for documenting how your class should be used.

Upvotes: 3

Raj Rao

Reputation: 9138

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

According to MSDN documentation:
"The exception that is thrown when a method call is invalid for the object's current state."
also:
"InvalidOperationException is used in cases when the failure to invoke a method is caused by reasons other than invalid arguments."

In this case obj is not an argument, which is why I would lean towards "InvalidOperationException"

The reason why I would not throw a NullReferenceException here: If you didnt add any special code, thats the exception that ".Net" would throw, so why add redundant code?

Upvotes: 9

tdammers

Reputation: 20721

I'd throw an InvalidOperationException, but only if: - it is legal for obj to be null, and it is the user's responsibility to check for this, or - it is not legal for obj to be null in the first place (i.e., obj != null is a class invariant)

If neither of the above is the case (that is, it is legal for obj to be null, and user code is not explicitly required to check for this before using the property), then I'd not throw at all but rather return null.

Upvotes: 1

Adam Lear

Reputation: 38768

You should not throw NullReferenceException. It is reserved for situations when a null object is dereferenced. In this case, if you were to throw NullReference, you might as well just leave the null check out and let the framework throw it for you when you attempt to access the obj's Name.

I'd throw InvalidOperationException instead.

Upvotes: 4