3:02 a.m.
What's the use case for having a public method: doSomething(Object
someArgs...) throws Throwable ?
Most of the time the user of such a facility will do:
catch(Throwable t)
{
throw new RuntimeException(t);
}
This leads to interesting situations whenever an ThreadDeath or
VirtualMachineError (/OOM) is thrown.
(Note that ThreadDeath should never occur, but that's another story.)
I think it's just laziness on the part of the facilitator to not
properly handle exceptions and that this construct should be abolished.
Carlo
11:43 a.m.
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.
E.g.
void storeMessage(Message message) throws Throwable
{
}
If that method fails in any way, even if it throw a RuntimeException or
Error then we need to handle it, since it would be a major problem if
the message didn't get saved.
The method could be declared to not throw Throwable and the caller would
just have to remember to catch (Throwable) but declaring the method as
throws Throwable prevents the possibility of the caller from forgetting
to do so.
FWIW It's debatable if it's really of much value but cases like the
above are where I have seen it used.
- DML
_______________________________________________
jboss-development mailing list
jboss-development(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/jboss-development
--
Tim Fox
Messaging Lead
JBoss - a division of Red Hat
http://jbossfox.blogspot.com/
irc.freenode.net#jbossmessaging
fox(a)redhat.com
12:28 p.m.
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.
/max
2:15 p.m.
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).
--
Jason T. Greene
JBoss, a division of Red Hat
2:35 p.m.
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"?
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
--
Andrew Lee Rubinger
Sr. Software Engineer
JBoss, a division of Red Hat, Inc.
http://exitcondition.alrubinger.com
3:51 p.m.
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
4:35 p.m.
Carlo de Wolf wrote:
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.
IMO this is correct because the Java language allows user code to throw
errors, and an interceptor should be able to throw any exception
declared by the method it is emulating. The only alternative is to wrap
it with a special exception that gets unwrapped, but this is just
pointless copying.
--
Jason T. Greene
JBoss, a division of Red Hat
1:58 a.m.
Jason T. Greene wrote:
Carlo de Wolf wrote:
> 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.
IMO this is correct because the Java language allows user code to
throw errors, and an interceptor should be able to throw any exception
declared by the method it is emulating. The only alternative is to
wrap it with a special exception that gets unwrapped, but this is just
pointless copying.
I disagree: it should be: invoke(..) throws Exception.
Both the user code and the invoke can throw unchecked exceptions
nonetheless. It's the handling of a checked exception that doesn't fit
the given method signature that gets special treatment.
Ergo throws Throwable in this case is still wrong.
Carlo
8:43 a.m.
Carlo de Wolf wrote:
Jason T. Greene wrote:
> Carlo de Wolf wrote:
>> 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.
>
> IMO this is correct because the Java language allows user code to
> throw errors, and an interceptor should be able to throw any exception
> declared by the method it is emulating. The only alternative is to
> wrap it with a special exception that gets unwrapped, but this is just
> pointless copying.
>
I disagree: it should be: invoke(..) throws Exception.
Both the user code and the invoke can throw unchecked exceptions
nonetheless. It's the handling of a checked exception that doesn't fit
the given method signature that gets special treatment.
Ergo throws Throwable in this case is still wrong.
The user code can also throw new Throwable(...). Not an Error, not an
Exception, just a Throwable. Any code that did that should be taken out
and shot, but it is allowed. And per section 11.2 of the JLS, that's a
checked exception:
"The unchecked exceptions classes are the class RuntimeException and its
subclasses, and the class Error and its subclasses. All other exception
classes are checked exception classes. "
Carlo
_______________________________________________
jboss-development mailing list
jboss-development(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/jboss-development
--
Brian Stansberry
Lead, AS Clustering
JBoss, a division of Red Hat
brian.stansberry(a)redhat.com
8:51 p.m.
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
2:44 a.m.
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@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/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
10:19 a.m.
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.
Hmm if Error's are not supposed to be
caught, it begs the question why
does Java throw them in the first place? It's a tease "Haha I'm going to
throw this error, you can watch it but you're not allowed to catch
it!!". If they're really supposed to be uncoverable why doesn't it just
make the JVM exit?
IMO the whole design or exceptions/errors/throwables in Java is a big
kludge.
/max
_______________________________________________
jboss-development mailing list
jboss-development(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/jboss-development
--
Tim Fox
Messaging Lead
JBoss - a division of Red Hat
http://jbossfox.blogspot.com/
irc.freenode.net#jbossmessaging
fox(a)redhat.com
12:42 p.m.
> Then do throws RuntimeException
>
> Error's are *nonrecoverable* since they are OutOfMemory or hard VM
> errors.No client can ever recover sanely.
Hmm if Error's are not supposed to be caught, it begs the question why
does Java throw them in the first place? It's a tease "Haha I'm going
to throw this error, you can watch it but you're not allowed to catch
it!!". If they're really supposed to be uncoverable why doesn't it
just make the JVM exit?
I did not say noone should catch them, just that no client
can recover
sanely (besides panic logging and resource cleanup with a quick rethrow
or hard exit, meaning no API should require catch Throwable.
IMO the whole design or exceptions/errors/throwables in Java is a big
kludge.
What I like about "throws ..." is that it is possible to see what
methods throws the exception, what I don't like is that you are
*required* to catch them.
/max
1:21 p.m.
On 05/06/2009 11:43 AM, 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.
E.g.
void storeMessage(Message message) throws Throwable
{
}
If that method fails in any way, even if it throw a RuntimeException or
Error then we need to handle it, since it would be a major problem if
the message didn't get saved.
The method could be declared to not throw Throwable and the caller would
just have to remember to catch (Throwable) but declaring the method as
throws Throwable prevents the possibility of the caller from forgetting
to do so.
That's a terrible idea. Please - never do this. :-)
The furthest one should go towards "reminding" the user to handle a runtime
exception is to add that exception to the "throws" clause of the method,
and document it.
- DML
10:07 a.m.
David M. Lloyd wrote:
On 05/06/2009 11:43 AM, 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.
>
> E.g.
>
> void storeMessage(Message message) throws Throwable
> {
> }
>
> If that method fails in any way, even if it throw a RuntimeException
> or Error then we need to handle it, since it would be a major problem
> if the message didn't get saved.
>
> The method could be declared to not throw Throwable and the caller
> would just have to remember to catch (Throwable) but declaring the
> method as throws Throwable prevents the possibility of the caller
> from forgetting to do so.
That's a terrible idea. Please - never do this. :-)
Like I said in the
previous mail, I'm not recommending people do this,
I'm reporting where I've seen it used in other code.
My personal view is all checked exceptions and throws clauses are evil.
The furthest one should go towards "reminding" the user to handle a
runtime exception is to add that exception to the "throws" clause of
the method, and document it.
- DML
_______________________________________________
jboss-development mailing list
jboss-development(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/jboss-development
--
Tim Fox
Messaging Lead
JBoss - a division of Red Hat
http://jbossfox.blogspot.com/
irc.freenode.net#jbossmessaging
fox(a)redhat.com
5478
days inactive
5480
days old
jboss-development@lists.jboss.org
15 comments
7 participants
participants (7)
-
Andrew Lee Rubinger -
Brian Stansberry -
Carlo de Wolf -
David M. Lloyd -
Jason T. Greene -
Max Rydahl Andersen -
Tim Fox