[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