swingx
  1. swingx
  2. SWINGX-1463

Stack trace in JXErrorPane lacks names of exception types

    Details

    • Type: Bug Bug
    • Status: Open
    • Priority: Minor Minor
    • Resolution: Unresolved
    • Affects Version/s: 1.6.2
    • Fix Version/s: None
    • Component/s: Error
    • Labels:
      None
    • Environment:

      Windows XP, jre/jdk 1.6.0_26

      Description

      Regular stack traces (such as those produced by printStackTrace()) include the name of the exception class for each nested exception. For example the following stack trace would represent a ClassNotFoundException wrapped inside a RuntimeException:

      java.lang.RuntimeException: oh no, some error just occured
              at experiments.Test.doSomething(Test.java:25)
              at experiments.Test.main(Test.java:31)
      Caused by: java.lang.ClassNotFoundException: some.unknownClass
              at java.net.URLClassLoader$1.run(URLClassLoader.java:202)
              at java.security.AccessController.doPrivileged(Native Method)
              at java.net.URLClassLoader.findClass(URLClassLoader.java:190)
              at java.lang.ClassLoader.loadClass(ClassLoader.java:306)
              at sun.misc.Launcher$AppClassLoader.loadClass(Launcher.java:301)
              at java.lang.ClassLoader.loadClass(ClassLoader.java:247)
              at java.lang.Class.forName0(Native Method)
              at java.lang.Class.forName(Class.java:169)
              at experiments.Test.load(Test.java:18)
              at experiments.Test.doSomething(Test.java:23)
      

      Unfortunately the "Stack Trace" section of the JXErrorPane omits all class names (only the first class name is displayed in the "Message" section). This way the user is unable to extract the actual cause of some higher level exception (as can be seen on the attached screenshot).
      I suggest the addition of the exception's class name to the output generated by the responsible method BasicErrorPaneUI.getDetailsAsHTML().

        Activity

        Hide
        mkresse added a comment -

        Just figured, that the usage of ex.toString() instead of ex.getMessage() should be sufficient to resolve the issue

        Cheers,
        Martin

        Show
        mkresse added a comment - Just figured, that the usage of ex.toString() instead of ex.getMessage() should be sufficient to resolve the issue Cheers, Martin

          People

          • Assignee:
            rah003
            Reporter:
            mkresse
          • Votes:
            1 Vote for this issue
            Watchers:
            2 Start watching this issue

            Dates

            • Created:
              Updated:

              Time Tracking

              Estimated:
              Original Estimate - 15 minutes
              15m
              Remaining:
              Remaining Estimate - 15 minutes
              15m
              Logged:
              Time Spent - Not Specified
              Not Specified