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@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