我应该抛出哪个异常来表示程序中的内部错误？

Question

Which exception should I use when the program reaches a logic state that I "know" won't happen, and if it does, something is terribly bad?

For example:

int SomeFunction(int arg) {
    SomeEnum x = Whatever(arg, somePrivateMember);
    switch (x) {
        case SomeEnum.Value1:
            return SomeFunction1();
        case SomeEnum.Value1:
            return SomeFunction2();
        default:
            throw new WhatTypeToThrow();
    }
}

Clearly, ArgumentException is a long-shot here since the invalid value for x could have come from a bug in Whatever(), or an invalid combination of any arguments and/or the current instance state.

I'm looking for something such as an InvalidProgramStateException, InternalErrorException or similar.

Of course I could define my own, but I wonder if there is a suitable exception in the framework.

Edit: Removed the simple sample code to reduce amount of ArgumentException answers.

Answer 1

InvalidOperationException 呢？

Answer 2

Why not the InvalidEnumArgumentException? It looks like it was designed specifically for this use-case.

Answer 3

Don't throw any specific exception type in the code you're looking at. Call Trace.Assert , or in this case even Trace.Fail to get a similar effect to Debug.Assert , except enabled even in release builds (assuming the settings aren't changed).

If the default trace listener, the one that offers a UI that offers to kill the whole program or launch a debugger, isn't appropriate for your needs, set up a custom trace listener in Trace.Listeners that causes a private exception type to be thrown whenever Trace.Fail is called (including when a Trace.Assert fails).

The exception type should be a private exception type because otherwise, callers may be tempted to try catching whatever exception type you're going to throw. For this particular exception type, you will want to make it as clear as possible that a future version of the method will no longer throw this particular exception. You don't want to be forced to throw a TraceFailedException or whatever you call it from now until eternity to preserve backwards compatibility.

---

Another answer mentioned Code Contracts already as an alternative. It is, in a similar way: you can call Contract.Assert(false) . This takes the same approach of making it customisable what happens if an assertion fails, but in this case, the default behaviour is to throw an exception, again of a type that is not externally accessible. To make the most of Code Contracts, however, you should be using the static rewriter, which has both pros and cons that I will not get into here. If for you the pros outweigh the cons, then by all means use it. If you prefer to avoid the static rewriter though, then I'd recommend avoiding the Contract class entirely, since it is not at all obvious which methods do and don't work.

Answer 4

I think ArgumentOutOfRangeException is valid here and it's what I use. It's the argument to the switch statement that is not handled as it's out of the range of handled values. I tend to code it like this, where the message tells it like it is:

switch (test)
{
    case SomeEnum.Woo:
        break;
    case SomeEnum.Yay:
        break;
    default:
    {
        string msg = string.Format("Value '{0}' for enum '{1}' is not handled.", 
            test, test.GetType().Name);

        throw new ArgumentOutOfRangeException(msg);
    }
}

Obviously the message is to your own tastes, but the basics are in that one. Adding the value of the enum to the message is useful not only to give detail concerning what known enum member was not handled, but also when there is an invalid enum ie the old "(666)SomeEnum" issue.

Value 'OhNoes' for enum 'SomeEnum' is not handled.

vs

Value '666' for enum 'SomeEnum' is not handled.

Answer 5

Here are suggestions that I've been given:

• ArgumentException : something is wrong with the value

• ArgumentNullException : the argument is null while this is not allowed

• ArgumentOutOfRangeException : the argument has a value outside of the valid range

Alternatively, derive your own exception class from ArgumentException .

An input is invalid if it is not valid at any time. While an input is unexpected if it is not valid for the current state of the system (for which InvalidOperationException is a reasonable choice in some situations).

See similar question and answer that I was given.

Answer 6

You should consider using Code Contracts to not only throw exceptions in this case, but document what the failed assumption is, perhaps with a friendly message to the programmer. If you were lucky, the function you called ( Whatever ) would have a Contract.Ensures which would catch this error before you got your hands on it.

Answer 7

program reaches a logic state that I "know" won't happen, and if it does, something is terribly bad.

In this case, I would throw an ApplicationException, log what you can, and exit the app. If things are that screwed up, you certainly shouldn't try to recover and/or continue.