jms-spec
  1. jms-spec
  2. JMS_SPEC-113

Clarify the difference (if any) between JMSException.getLinkedException() and JMSException.getCause()

    Details

    • Type: Improvement Improvement
    • Status: Open
    • Priority: Major Major
    • Resolution: Unresolved
    • Affects Version/s: 2.0
    • Fix Version/s: None
    • Labels:
      None

      Description

      JMSException.getLinkedException() is usually containing the provider-specific Exception object, but there's also already the inherited Exception.getCause() method.
      JMS Providers could potentially return different things in each method, which would be confusing.

      Also, 'exception un-nesting code' would typically use Exception.getCause() multiple times until getCause() returns null to get to the root cause which then usually contains a better error description. Since this 'exception un-nesting code' could catch exceptions from multiple API's it would be nice if JMS behaves just like any other library (let getCause() return the cause of the exception).

      My proposal would be to require JMS providers to implement JMSException.getCause() like this:

          @Override
          public Throwable getCause()
          {
              return getLinkedException();
          }
      

      That way, JMS wouldn't play a special role when interpreting the cause of an exception.

        Activity

        axel_podehl created issue -
        Nigel Deakin made changes -
        Field Original Value New Value
        Description JMSException.getLinkedException() is usually containing the provider-specific Exception object, but there's also already the inherited Exception.getCause() method.
        JMS Providers could potentially return different things in each method, which would be confusing.

        Also, 'exception un-nesting code' would typically use Exception.getCause() multiple times until getCause() returns null to get to the root cause which then usually contains a better error description. Since this 'exception un-nesting code' could catch exceptions from multiple API's it would be nice if JMS behaves just like any other library (let getCause() return the cause of the exception).

        My proposal would be to require JMS providers to implement JMSException.getCause() like this:

            @Override
            public Throwable getCause()
            {
                return getLinkedException();
            }

        That way, JMS wouldn't play a special role when interpreting the cause of an exception.
        {{JMSException.getLinkedException()}} is usually containing the provider-specific Exception object, but there's also already the inherited {{Exception.getCause()}} method.
        JMS Providers could potentially return different things in each method, which would be confusing.

        Also, 'exception un-nesting code' would typically use {{Exception.getCause()}} multiple times until {{getCause()}} returns {{null}} to get to the root cause which then usually contains a better error description. Since this 'exception un-nesting code' could catch exceptions from multiple API's it would be nice if JMS behaves just like any other library (let {{getCause()}} return the cause of the exception).

        My proposal would be to require JMS providers to implement {{JMSException.getCause()}} like this:

        {noformat}
            @Override
            public Throwable getCause()
            {
                return getLinkedException();
            }
        {noformat}

        That way, JMS wouldn't play a special role when interpreting the cause of an exception.
        Nigel Deakin made changes -
        Tags jms21-forreview-minor

          People

          • Assignee:
            Unassigned
            Reporter:
            axel_podehl
          • Votes:
            0 Vote for this issue
            Watchers:
            1 Start watching this issue

            Dates

            • Created:
              Updated: