views:

132

answers:

4

Hello,

I am actually working on a Framework development, which means require a really strong coding methodology.

I am facing a problem where I do not know which System.Exception derivated class I need to throw. Basically the case is when I have a class with fields that can be optionnaly initialized by the constructor and that have methods using these fields. Which exception must I throw if the user did not initialized these fields? (which means they are null)

Here is an example:

public class MyConnection
{
    private Uri endpointUri;

    public Uri EndpointUri
    {
        get
        {
            return this.endpointUri;
        }

        set
        {
            this.endpointUri = value;
        }
    }

    public MyConnection()
    {
    }

    public MyConnection(Uri endpointUri)
    {
        this.endpointUri = endpointUri;
    }

    public FileStream GetFile()
    {
        if (this.endpointUri != null)
        {
            // My doer methods
        }
        else
        {
            throw new TheExceptionINeedToThrow("endpointUri", ...);
        }                
    }
}

Note that I have been reading the whole "Framework Design Guidelines" chapter concerning exception handling and throwing and that I did not found any solution fitting this exact case. Or maybe I misunderstood something ...

Thanks for your help.

EDIT : The fact that I provide an empty constructor seems a bit confusing regarding my problem but it is completely voluntary. In some objects that have to comply with a range of different states that cannot be duplicated in multiple objects it is sometimes useful.

A: 

NullReferenceException, InvalidArgumentExecption or ApplicationException would all be fine as long as the exception description clearly states what it is that is null.

Kragen
None of those seem appropriate to me - the first two for reasons I've given elsewhere; the third is completely nondescript in terms of the type itself, and guidance is generally against using ApplicationException these days.
Jon Skeet
@Jon: I'd say guidance is explicitly against ApplicationException
Jeff Yates
@Jeff: Indeed - I wouldn't be surprised to see *some* recommendations for it though, which is why I was slightly cautious :)
Jon Skeet
Well my point was more that it doesn't really matter what exception is thrown as long as its clearly identifiable what's happened.
Kragen
@Jon - why the guidance against ApplicationException?
Kragen
@Kragen - if you want to handle the exception in code (as opposed to reading about it in a log entry), the exception you choose to throw does matter.
Jeff Sternal
@JeffS I'm struggling to imagine a scenario where waiting for an exception to be thrown would be a good way of handling a member property not being set (also see http://www.joelonsoftware.com/items/2003/10/13.html)
Kragen
@Kragen, you may be right - I can imagine some scenarios, but they're pretty unlikely. Then again, as long as there's a good choice that accurately represents what's happened, why not use that in case one of those exotic circumstances arises?
Jeff Sternal
@Kragen, guidelines explains that SystemException (from which common exceptions derives) indicates an exception thrown from the CLR and that ApplicationException indicates an exception thrown from an non-CLR program.
Ucodia
@Kragen: concerning NullReferenceException, FxCop CA2201 rule say this: http://msdn.microsoft.com/en-us/library/ms182338(VS.80).aspx
Ucodia
+12  A: 

Throw InvalidOperationException:

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

Note that the null reference isn't being passed into the method - it's already there when the method is called - so it's the object's current state which is invalid, not an argument.

However, it would be better to prevent the object from being created in this way to start with, if at all possible - does it have to be a writable property? Would you ever want an instance which did have a null endpoint URI?

Jon Skeet
Notice the explicit default constructor, which (probably) implies that he does.
SLaks
@SLaks: I've noticed it, but I'm questioning the wisdom of it.
Jon Skeet
I'm bowing out in deference to the more complete answer!
Jeff Sternal
Thanks, this answer is quite satisfying. In fact I think I missunderstood the "state" term used in the book concerning InvalidOperationException.
Ucodia
I edited my question and added some more informations concerning the object state and why I provide an empty ctor in my example. So yes in some case these fields can be null.
Ucodia
@TheRHCP: Fair enough. I guess we don't know enough about your situation to judge - it's worth *trying* to avoid ever having invalid object state, but sometimes it's tricky.
Jon Skeet
+4  A: 

InvalidOperationException

C. Ross
+1  A: 

Like the others i will recommend InvalidOperationException (Because John Skeet said it) :)

if you call a function with a null parameter then i will use

ArgumentNullException

ps