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

Answer 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.

Answer 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.

Answer 3

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.

Answer 4

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.

Answer 5

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;
    }
}

1. We should not be throwing AssertionError because it should be reserved for actual assertions.
2. 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

Answer 6

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.