Is actively throwing AssertionError in Java good practice? [duplicate]

问题

Looking through Joshua Bloch's 'Effective Java - Second Edition', I stumbled upon the following code on page 152:

double apply(double x, double y) {
    switch(this) {
        case PLUS:   return x + y;
        case MINUS:  return x - y;
        case TIMES:  return x * y;
        case DIVIDE: return x / y;
    }
    throw new AssertionError("Unknown op: " + this);
}

Now what confuses me is, that the AssertionError is actively thrown. Is that considered good practice? To my understanding assertions are used to not interfeer with the code such that when the java programming is started without assertions enabled and the assert-statements are therefore not executed, the behavior doesn't change. I would be rather confused, if I'd get a AssertionException when I run a program without even having assertions enabled.

Even though I understand that the example case might happen quite often, that you analyze a couple of different options and if it is none of them, you should throw an exception.

So is it good practice to throw an AssertionException here, or would it be better to throw a different one? If so, which one would fit best? Maybe IllegalArgumentException?

Edit for clarification: My question is not about whether we should throw an Errorhere, but if we want to throw an Exception or an Error, which one should it be? And is it good practice to actively throw AssertionErrors? The documentation says Thrown to indicate that an assertion has failed, so I have the feeling that we should not actively throw it. Is that correct?

Second Edit: Clear question: Is it good practice to actively throw an AssertionError, or should that be avoided, even though it is possible? (My guess reading the docs is the latter)

回答1:

I would agree with Mr. Bloch here - the alternatives (IllegalArgumentException, IllegalStateException, and UnsupportedOperationException) do not properly convey the severity of the issue, and callers may erroneously try to catch and handle this case. In fact if this line is ever reached the program in question is broken, and the only sane thing to do is exit.

The point here is that enum has a finite set of values, thus it should be impossible to reach the throw line - it would only occur if the enum's definition has changed without also fixing this instance method. Throwing a RuntimeException suggests the caller made a mistake, when in fact the method (and the enum) itself is broken. Explicitly raising an AssertionError correctly indicates the invariants this method expects have been violated.

Guava has a helpful article which breaks down when to raise different types of exceptions. They write:

A conventional assertion is a check that should only fail if the class itself (that contains the check) is broken in some way. (In some cases this can extend to the package.) These can take various forms including postconditions, class invariants, and internal preconditions (on non-public methods).

An impossible-condition check is one that cannot possibly fail unless surrounding code is later modified, or our deepest assumptions about platform behavior are grossly violated. These should be unnecessary but are often forced because the compiler can't recognize that a statement is unreachable, or because we know something about the control flow that the compiler cannot deduce.

The page says an AssertionError is the recommended way to handle these cases. The comments in their Verify class also offers some useful insights about choosing exceptions. In cases where AssertionError seems too strong raising a VerifyException can be a good compromise.

As to the specific question of Error or RuntimeException, it doesn't really matter (both are unchecked and therefore will potentially travel up the call stack without being caught), but callers are more likely to attempt to recover from a RuntimeException. Crashing the application in a case like this is a feature, because otherwise we're continuing to run an application that is (at this point) demonstrably incorrect. It's certainly less likely that callers will catch and handle AssertionError (or Error or Throwable), but of course callers can do whatever they want.

回答2:

In my opinion, an AssertionError would be incorrect to use here.

From the docs, an AssertionError extends base class Error

An Error is a subclass of Throwable that indicates serious problems that a reasonable application should not try to catch.

An error should be fatal, whereas I would expect your program to handle this, and display the user a warning message about the unknown operation.

If anything here, I would expect an UnsupportedOperationException to be thrown, and handled elsewhere in the call stack.

Thrown to indicate that the requested operation is not supported.

Consider the case where, not in a calculator, but any code flow that uses ENUMs:

If a developer were to add a new value to an existing enum, I would not expect functions that make use of this existing enum to invoke an error, just because the new value is not supported.

回答3:

Regarding errors, the Java Tutorial states:

The second kind of exception is the error. These are exceptional conditions that are external to the application, and that the application usually cannot anticipate or recover from.

Also, the Programming With Assertions guide states:

Do not use assertions for argument checking in public methods.

So I think Exception are the right way to check for this kind of cases.

I recommend using a new UnsupportedOperationException("Operator " + name() + " is not supported."); since it better describe the problem in my opinion (i.e. a developer added an enum value but forgot to implement the required case).

However I think that this sample case should use an AbstractEnum design pattern instead of a switch:

PLUS {
    double apply(double x, double y) {
        return x + y;
    }
},
MINUS {
    double apply(double x, double y) {
        return x - y;
    }
},
TIMES {
    double apply(double x, double y) {
        return x * y;
    }
},
DIVIDE {
    double apply(double x, double y) {
        return x / y;
    }
};

abstract double apply(double x, double y);

It is less error prone since this code will not compile until every case implements apply.

回答4:

I would prefer

    double apply(double x, double y) {
    switch(this) {
        case PLUS:   return x + y;
        case MINUS:  return x - y;
        case TIMES:  return x * y;
        default: assert this==DIVIDE: return x / y;
    }
}

We should not be throwing AssertionError because it should be reserved for actual assertions.
Other than assertions and some catch blocks there should not be a single bit of code that can not practicably reached.

But I would most prefer https://stackoverflow.com/a/41324246/348975

回答5:

I think both AssertionError or IllegalAE are not very good here. Assertion Error is not good as indicated in Matt's answer. And the arguments are not wrong here, those are just passed to a method on wrong this operation. So IAE may not be good as well. Of course this is an Opinion based question and answer as well.

Also, I am not sure enabling assertion is mandatory for throwing AssertionError or an assertionError means assertions were enabled.

回答6:

As I understand, your method is a method of enum object. In most cases when somebody adds new enum value, he should modify "apply" method as well. You should throw UnsupportedOperationException in this case.

来源：https://stackoverflow.com/questions/41323735/is-actively-throwing-assertionerror-in-java-good-practice

标签

java

assertion