Uploaded image for project: 'JDK'
  1. JDK
  2. JDK-4209652

Put recursive exception handling (ala InvocationTargetException) into Throwable!

    XMLWordPrintable

    Details

    • Subcomponent:
    • Resolved In Build:
      beta
    • CPU:
      generic, x86
    • OS:
      generic, windows_nt

      Description



      Name: krT82822 Date: 02/08/99


      It seems that lots of exceptions need support for "internal" or "child" exceptions ala InvocationTargetException. For instance, you often have to
      catch exceptions of one type and re-throw them as another. If this functionality was built into Throwable, it would mean that I (and lots of others)
      wouldn't have to make incompatible implementations of this functionality. For example, the OO-RDBMS mapping product we're using (TOPLink)
      implements this in their TOPLinkException, and so do we in our code. However, using this is a nightmare because the exception handling code
      has to support each type of exception differently.

      Note also that this could provide another, even more useful feature - the ability to avoid the "got an silly exception in a finally clause which blows
      away the important exception I had in the first place" which is pointed out in the Java book "Thinking in Java" by Bruce Eckel (www.bruceeckel.com).
      Simply append any exceptions found whilst processing the original exception as "sub" exceptions using the mechanism outlined above and I belive
      you have avoided the problem. Of course, how the VM would actually handle that may be harder but thats your job, huh?

      :-)
      (Review ID: 52287)
      ======================================================================

      Name: rlT66838 Date: 08/10/99


      In fact this particular one is just an instance of a more general
      need to have the JDK exceptions carry useful information about what
      caused them and to make that information available programatically.

      It would improve error handling to be able to
      find out from a ClassCastException what class
      (or interface) the cast was to and what class
      it was from. Something like:

      public Class targetClass();
      public Class sourceClass();

      or maybe just return Strings with the class name
      and folks can Class.forName() them if they need
      to.

      P.S. I realize that the message currently returns
      the name of the class the cast was from. But
      that's not part of the contract.

      Another thought: you might need to make these
      methods possibly return null if the class isn't
      known. But since most ClassCastExceptions should
      be generated by the VM and it certainly knows both
      classes.
      (Review ID: 25234)
      ======================================================================

        Attachments

          Issue Links

            Activity

              People

              Assignee:
              jjb Josh Bloch
              Reporter:
              kryansunw Kevin Ryan (Inactive)
              Votes:
              0 Vote for this issue
              Watchers:
              1 Start watching this issue

                Dates

                Created:
                Updated:
                Resolved:
                Imported:
                Indexed: