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)
======================================================================