Re: [jboss-dev] throws Throwable
Andrew Lee Rubinger wrote:
Carlo de Wolf wrote:
> ...
>
> The only thing is that the guideline above invalidates
> IllegalStateException and IllegalArgumentException, because both are
> generally recoverable and are RuntimeExceptions.
> In those cases I would say that you should add boolean isValid(...)
> and boolean canStart(...), because then it becomes a programming
> error again to call myMethod wrongly.
I'm so glad that you point to Josh Bloch as a reference. :D
"Item 38: Check Parameters for validity".
I won't plagiarize too heavily his example, but it does specifically
mention using @throws Javadocs tags for IllegalArgumentException in
order to do precondition checks on method input.
Also, if you pass null to "myMethod", that doesn't sound too
recoverable to me - more like a bug that would benefit from a nice
descriptive error message and appropriate exception. To be
recoverable from this would mean that user code would be catching the
exception and taking some other course, which reads a lot like "using
Exceptions for control flow", another no-no.
You don't know where the null
in question came from. Consider the
following scenario:
1. Given a text field and a button
2. Without entering text press the button, assume the resultant is null
3. The resultant is passed to myMessage
This situation is perfectly recoverable.
Now consider the following scenario:
1. Assume we need to keep an audit trail
2. class AuditTrail { void auditMessage(Message msg) {
auditLog.write(auditId++, msg.getContents()); } }
3. auditMessage(<Message@1>);
4. auditMessage(null);
The system is now in an unrecoverable condition, because we would have
gaps in the audit trail.
So the assumption that null being passed into a method isn't recoverable
is wrong. It's the implementation that makes something recoverable or not.
Regardless throwing or catching Throwable in the auditMessage or
myMethod would only make matters worse.
Carlo
eg. @see
http://anonsvn.jboss.org/repos/jbossas/projects/bootstrap/trunk/spi/src/m...
...lots of state-based operations in there, where the state of the
server dictates whether calling a method is valid. Instead of
catching IllegalStateException after some attempt, user code should
first be calling "getState()" and taking appropriate action.
S,
ALR