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/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
--
Andrew Lee Rubinger
Sr. Software Engineer
JBoss, a division of Red Hat, Inc.
http://exitcondition.alrubinger.com