[jboss-dev] throws Throwable
Carlo de Wolf
cdewolf at redhat.com
Thu May 7 03:44:14 EDT 2009
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 at 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/main/java/org/jboss/bootstrap/spi/server/Server.java
>
>
> ...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
>
More information about the jboss-development
mailing list