jms-spec
  1. jms-spec
  2. JMS_SPEC-35

Remove the use of unchecked exceptions from the JMS API as far as possible

    Details

    • Type: Improvement Improvement
    • Status: Closed
    • Priority: Major Major
    • Resolution: Won't Fix
    • Affects Version/s: 1.1
    • Fix Version/s: None
    • Labels:
      None

      Description

      In JMS 1.1, almost every method in the JMS API throws a javax.jms.JMSException, which is a checked exception and so needs to be caught and handled by the application.

      In practice the developer rarely knows what to do in such circumstances, and provides some generic exception handling that is not specific to JMSException. The result is to clutter the application code with boilerplate exception handling which adds little value.

      In addition, the fact that so many API methods throw this checked exception makes it more difficult to construct frameworks on top of the JMS API.

      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 would not need to be changed.

        Activity

        Hide
        rdohna added a comment -

        fixed typos

        Show
        rdohna added a comment - fixed typos
        Hide
        Nigel Deakin added a comment -

        The Java Tutorial contains the following useful discussion of when an exception should be checked or unchecked.
        http://download.oracle.com/javase/tutorial/essential/exceptions/runtime.html

        This includes the advice:

        If a client can reasonably be expected to recover from an exception, make it a checked exception. If a client cannot do anything to recover from the exception, make it an unchecked exception.

        Given that in most cases a client cannot recover from a JMSException (which is why they tend to log the exception and rethrow it), making it an unchecked exception seems appropriate in this case.

        Show
        Nigel Deakin added a comment - The Java Tutorial contains the following useful discussion of when an exception should be checked or unchecked. http://download.oracle.com/javase/tutorial/essential/exceptions/runtime.html This includes the advice: If a client can reasonably be expected to recover from an exception, make it a checked exception. If a client cannot do anything to recover from the exception, make it an unchecked exception. Given that in most cases a client cannot recover from a JMSException (which is why they tend to log the exception and rethrow it), making it an unchecked exception seems appropriate in this case.
        Hide
        Nigel Deakin added a comment -

        I've received this comment:

        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.

        This means that we cannot guarantee that this change will never require code changes.

        Show
        Nigel Deakin added a comment - I've received this comment: 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. This means that we cannot guarantee that this change will never require code changes.
        Hide
        Nigel Deakin added a comment -

        Unfortunately, as noted in the previous comment, 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

        Show
        Nigel Deakin added a comment - Unfortunately, as noted in the previous comment, 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
        Hide
        Nigel Deakin added a comment -

        Since this proposal cannot be implemented (for existing methods) without breaking Java EE compatibility requirements, it will be closed with a resolution of "won't fix".

        Show
        Nigel Deakin added a comment - Since this proposal cannot be implemented (for existing methods) without breaking Java EE compatibility requirements, it will be closed with a resolution of "won't fix".

          People

          • Assignee:
            Nigel Deakin
            Reporter:
            Nigel Deakin
          • Votes:
            0 Vote for this issue
            Watchers:
            1 Start watching this issue

            Dates

            • Created:
              Updated:
              Resolved: