Re: Use of AssertionError
- From: Lew <lew@xxxxxxxxxxxxx>
- Date: Sun, 30 Dec 2007 16:49:25 -0500
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?
--
Lew
.
- Follow-Ups:
- Re: Use of AssertionError
- From: Daniel Pitts
- Re: Use of AssertionError
- References:
- Use of AssertionError
- From: Joshua Cranmer
- Use of AssertionError
- Prev by Date: Re: Use of AssertionError
- Next by Date: Re: New File with a Directory
- Previous by thread: Re: Use of AssertionError
- Next by thread: Re: Use of AssertionError
- Index(es):
Relevant Pages
|
|