On 20/10/2011 16:51, Nigel Deakin wrote:
> OK, remember this one?
> http://java.net/jira/browse/JMS_SPEC-35
>
>> "It is therefore proposed that the JSR 343 Expert Group consider whether they should change the JMS API to throw
>> unchecked rather than checked exceptions as much as possible. One simple way of achieving this would be to change
>> {{javax.jms.JMSException}} to extend {{java.lang.RuntimeException}} instead of {{java.lang.Exception}}.
>>
>> "Existing applications which explicitly catch {JMSException}}s would not need to be changed. "
>
> A colleague has pointed out a case where this change would change the behaviour of existing binary code, and prevent the
> source code compiling.
>
> try {
> a{};
> } catch (RuntimeException rte){
> b{};
> } catch (MyException e) {
> c();
> }
>
> In JMS 1.1, if a JMSException in throw in a(), then c() will be called. However if JMSException is changed as proposed
> above, b() will be called. Also, the above code will not compile because c() is unreachable.
>
> It is possible to contrive similar cases, but I think the above is quite a plausible existing use case.
>
> This means that we cannot guarantee that this change will never change existing application behaviour, and will never
> require application code changes.
>
> I think this probably means we can't make this change in JMS 2.0. Which is a pity.
As noted above, to simply make JMSException a subtype of RuntimeException would be an incompatible change as defined in
the Java EE compatibility requirements:
http://java.net/projects/javaee-spec/pages/CompatibilityRequirements
This means that this change is not allowed.
There is no reason why new exception classes cannot be defined which are subtypes of RuntimeException and which are
thrown by any new methods that are added to JMS. This has been done in the proposed simplified JMS API:
http://java.net/jira/browse/JMS_SPEC-64
I'm therefore closing this issue with a resolution of "won't fix".
Nigel