Details
-
Wish
-
Status: Open
-
Minor
-
Resolution: Unresolved
-
The Latest Development Code
-
None
-
Security Level: No security risk; visible to anyone (Ordinary problems in Xalan projects. Anybody can view the issue.)
-
None
-
PatchAvailable
Description
The current Xalan-J code contains a lot of places where one exception causes another exception, Possibly via some intermediate ErrorMsg object or similar. The message text of the exception is usually passed along, but more detailed information, especially the stack trace, is lost. It would be great for debugging if Xalan could make use of JDK 1.4 exception chaining where available. LSSerializerImpl already does so for LSExceptions, but that's only one case of many.
So what I suggest is
1. Introduce some static method "chainException", probably in a dedicated helper class, to call initCause when available, and deal with all the messy reflection handling this involves.
2. Introduce chaining constructors for exceptions defined in Xalan, which internally call this method unless the superclass provides a chaining constructor as well, in order to make code more readable than with explicit chaining calls all over the place.
3. Allow for non-Throwable classes like ErrorMsg to carry an exception as well, initialize it upon or immediately after creation, and use it for chaining when an exception is generated from the error message.
Keywords like "getMessage" and "catch" might be suitable to find locations in need of chaining. As I said, they appear to be all over the place.