[jboss-dev] throws Throwable

[Carlo de Wolf]

Andrew Lee Rubinger wrote:
> Jason T. Greene wrote:
>> Max Rydahl Andersen wrote:
>>>
>>>
>>> Tim Fox wrote:
>>>> David M. Lloyd wrote:
>>>>> On 05/05/2009 03:02 AM, Carlo de Wolf wrote:
>>>>>> What's the use case for having a public method: 
>>>>>> doSomething(Object someArgs...) throws Throwable ? 
>>>>>
>>>>> No valid use cases exist afaik.  Any method that throws Throwable 
>>>>> should die, if it's within our power to kill it. 
>>>> Declaring a method as "throws Throwable" forces the caller to 
>>>> handle the exception even if the exception/error thrown is unchecked.
>>> Then do throws RuntimeException
>>>
>>> Error's are *nonrecoverable* since they are OutOfMemory or hard VM 
>>> errors.No client can ever recover sanely.
>>
>> One valid case for throwing Throwable is a generic invocation mechanism
>> (interceptors, proxies, etc).
>
> 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.

Carlo