views:

125

answers:

3

In .NET, what type of exception should be thrown if someone passes an illegal value to the set { } part of a property?

Example:

public string Provider
{
    get { return _provider; }
    set
    {
        if (String.IsNullOrEmpty(value)) throw new Exception("Provider cannot be null or empty."); //what type of exception should be thrown here instead?
        _provider = value;
    }
}


Note:

I'm asking this question as it applies to .NET, but it could apply to many other languages as well. So if you have a good answer that applies to something other than the .NET framework, please post!

+7  A: 

ArgumentException, ArgumentOutOfRangeException, ArgumentNullException or similar.

ctacke
+1  A: 

I would not throw an exception in that case. If the property is a string, then I can set it to "" or null. The exception should be thrown when I try to use that property (like in a Connect() function), with the message indicating the function failed because the property was invalid.

Jon B
+1 for design guideline
Tom Anderson
For this specific example this may make sense. If, however, the value was used in the setter for more than storing, I'd still throw.
ctacke
@ctacke - the setter should only be used for storage of the value. If more action is needed, then a SetProvider(string value) function should be used.
Jon B
What exception should be thrown then from the Connect() function?
Terrapin
@Terrapin - I would probably create my own exception for this. You might prefer the SetProvider(string value) solution instead, and throw ArgumentException from there.
Jon B
@Jon B: What if the setter also raises an event and the event contains the data? Should it raise with null or inform the setter through an Exception? I'd assert that it's best to not send out invalid data at all than to rely on any number of unknown receivers to look for it.
ctacke
Agreed - SetProvider is probably more logical in this specific case.
ctacke
@ctackle - I would have the event report the invalid data, if the event is simply "OnPropertyChanged".
Jon B
+1  A: 

Generally speaking, I'd disagree with Jon B regarding when to throw the exception - if it is thrown on the call to set() it will capture the context of when the invalid value was set. On the other hand, if you just set it to some dummy value and throw the exception elsewhere, then depending on the approach you take, the client will either see the dummy value with no indication that this was not the value actually set, or they will receive an exception that doesn't give them any idea of who is responsible for the invalid state or how to rectify it.

Now in some situations this technique might make sense - if for some unavoidable reason the property is extremely volatile, and you've decided that it's fine for illegal properties to be set transiently, but (based on some external synchronisation) the client is not allowed to retrieve the property until it is known to be a legal, stable value. This isn't great either, but I'm sure it's possible to be in a situation where you can't help this situation.

And since you asked about languages other than .NET, in Java I would use an IllegalArgumentException in the general case - perhaps a good old NullPointerException if the argument is null.

Andrzej Doyle