Re: Use of AssertionError

Lew wrote:
Joshua Cranmer wrote:
public static void getClass(String name) {
for (SourceHandler handler : handlers) {
if (handler.hasClass(name))
return; // Use this handler as the class
}
// Since our last handler claims to handle everything, we should
// never get here.
throw new AssertionError();
}
}

Where I throw the assertion error explicitly, I want to put an `assert false;' statement in (with a comment, of course), but then I would need to insert a `return null;' at the end of the method, which would invalidate the method contract which forbids null as a result but assertions may not be on.

Is it more appropriate to put a RuntimeException or other type of error instead of using an AssertionError here?

I would use IllegalStateException. The problem is that this depends on data being wrong, i.e., a run-time condition that caused 'handlers' not to be initialized correctly. This is not an algorithmic failure but a state failure. The program is in an illegal state, therefore IllegalStateException.

Client code will not be able to recover from an AssertionError. Is that what you want, or would you prefer that the client can detect and log the exception, perhaps by plugging in its own default handler when it hits this?

Don't you think it might surprise a sysadmin to see an AssertionError if they've turned off asserts?

How about this case:

public String getSomethingRandom() {
final int value = random.nextInt(3);
switch (value) {
case 0:
return "Nothing here.";
case 1:
return "Got something!";
case 2:
return "Twice the fun?";
default:
throw new AssertionError("Something wrong!");
}
}


--
Daniel Pitts' Tech Blog: <http://virtualinfinity.net/wordpress/>
.

Relevant Pages

  • Use of AssertionError
    ... NullPointerException-IllegalArgumentException-AssertionError thread, I was just wondering if my use of AssertionError in one case was valid. ... This is a very pared-down interface of the code: ... public static void addHandler(SourceHandler handler) { ...
    (comp.lang.java.programmer)
  • Re: Use of AssertionError
    ... // Use this handler as the class ... Is it more appropriate to put a RuntimeException or other type of error instead of using an AssertionError here? ... The program is in an illegal state, therefore IllegalStateException. ... Client code will not be able to recover from an AssertionError. ...
    (comp.lang.java.programmer)
  • Re: Use of AssertionError
    ... // Use this handler as the class ... Is it more appropriate to put a RuntimeException or other type of error instead of using an AssertionError here? ... The program is in an illegal state, therefore IllegalStateException. ... Client code will not be able to recover from an AssertionError. ...
    (comp.lang.java.programmer)
  • Re: Use of AssertionError
    ... NullPointerException-IllegalArgumentException-AssertionError thread, I was just wondering if my use of AssertionError in one case was valid. ... This is a very pared-down interface of the code: ... // Use this handler as the class ... Where I throw the assertion error explicitly, I want to put an `assert false;' statement in, but then I would need to insert a `return null;' at the end of the method, which would invalidate the method contract which forbids null as a result but assertions may not be on. ...
    (comp.lang.java.programmer)
  • Re: Direct Remoting event issue?
    ... The Event Wrapper Class compiled fine into a dll, but using it in the client ... The client code gives an error when compiling the client code at this ... EventWrapper wrapper = new EventWrapper; ... Client handler have to be hooked ...
    (microsoft.public.dotnet.framework.remoting)