Consistency is important, but progress is as well. I think that methods that really are just variants of old methods with just different arguments should be left consistent and still declare JMSException. But when they are really new, i.e. reside in a new interface or have a new name, then progress should not be hindered :-)
On 2012-01-09, at 11:22, Nigel Deakin wrote:
> John,
>
> JMSRuntimeException is part of the simplified API, which is open for comments. Currently I'm only proposing we use this exception (and its subtypes) for methods on MessagingContext.
>
> We could use it for new methods on existing interfaces but although that would not break compatibility I suspect it might be confusing. I think it's probably best that any new methods we add to existing interfaces (e.g. the new createSession methods on Connection) should in general continue to use JMSException for consistency.
>
> Does that answer your question?
>
> Nigel
>
> On 07/01/2012 00:59, John D. Ament wrote:
>>
>> 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
>>
>> "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
>>
>>