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 <mailto: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
>
>