Exception subclass for Bad Object State?

I'm a moderate fan of using Exception subtypes to help describe the problem that caused the exception. For instance, let's say that I'm writing a method that does not allow int values greater than 100 to be passed in as arguments. I'll often start the method with a condition to guard against this, and throw an exception if it occurs. I'll probably throw a System.Argument exception (with an appropriate message, inner exception, and Data) to indicate this.

Righ开发者_Python百科t now I have a class which has two properties. For the object to be considered "valid", exactly one of these properties must have a non-null value, and the other one must be null. I happen to have a defect case where this isn't true, and I want to throw an exception when this is detected.

My question is: what is the best Exception subclass to use in this case? I don't see an (Invalid)StateException subclass. ApplicationException is the obvious fallback choice, but it's very generic and so I'm hoping for something better.

My particular interest at the moment is in .NET Exception subclasses, but since this same problem applies to multiple languages I wouldn't consider discussions of other language solutions to be too off-topic. For instance: Java has IllegalStateException which seems to describe my needs perfectly. I've also favorited a similar question for Ruby.

Simple Answer (on topic):

If we're purely talking about API misuse and the design means such situations are unavoidable, InvalidOperationException is probably what you're looking for. It's generally used when the caller has done something incorrect, such as calling a particular method on an object when it is not in a valid state to handle the call. E.g. calling "pop" on an empty stack, or calling a "Send" method on a socket that has yet to have its "Connect" method called.

Not so Simple Answer (slightly off topic):

It depends. Things that spring to mind:

• Is your class being misused by callers or is it bugged?
• Can you change the API to avoid the situation entirely?
• Can you add validation steps elsewhere to detect the condition as it occurs?

If you can avoid the situation occurring or detect the invalid state sooner/in a different place (e.g. when a value is set), then it may be better to change the design.

If the class has a bug and the case should never happen, then I'd think twice before adding an exception for it. I really like Eric's answer to another question regarding such situations.

I think the closest out of the box exception is InvalidOperationException.

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