[jboss-dev] throws Throwable

Andrew Lee Rubinger andrew.rubinger at redhat.com
Wed May 6 21:51:38 EDT 2009


Carlo de Wolf wrote:
> Andrew Lee Rubinger wrote:
>> Just because it's generic doesn't mean the caller can do anything 
>> about it.  In that case why not just "throws Exception"?
> As per javax.interceptor.InvocationContext.proceed().
> But InvocationHandler.invoke throws a Throwable, which I think is wrong.
> 
> It seems that the important bit is how the caller is excepted to behave.
> I think Joshua Bloch sums it up nicely with "use checked exception for 
> recoverable conditions and run-time exceptions for programming errors".
> Tim's example shows a poor storeMessage implementation, because the 
> implementer forced the problem onto the caller instead of solving it.
>>
>> BTW as practice lately I tend to declare and document unchecked 
>> exceptions to give the user a clear idea of what to expect, ie:
>>
>> /**
>>  * @throws IllegalStateException If not yet initialized
>>  * @throws IllegalArgumentException If you gave me null, bastard
>>  */
>> myMethod(String arg) throws IllegalStateException, 
>> IllegalArgumentException{}
>>
>> S,
>> ALR
>>
> 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.

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

-- 
Andrew Lee Rubinger
Sr. Software Engineer
JBoss, a division of Red Hat, Inc.
http://exitcondition.alrubinger.com



More information about the jboss-development mailing list