HI Nigel
Do we need a separate issue for the runtime exception definition? will it
cause any confusion when we have similar methods with runtime and checked
exceptions?
On Fri, Jan 6, 2012 at 9:30 AM, Nigel Deakin <nigel.deakin_at_oracle.com>wrote:
> On 20/10/2011 16:51, Nigel Deakin wrote:
>
>> OK, remember this one?
>> http://java.net/jira/browse/**JMS_SPEC-35<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<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<http://java.net/jira/browse/JMS_SPEC-64>
>
> I'm therefore closing this issue with a resolution of "won't fix".
>
> Nigel
>
>