[Webmacro-devel] New RethrowableException impl..

[<Web...@St...>]

The mix of RethrowableException's exception-chaining and java 1.4's
exception chaining causes, at least on my setup, often extremely long
stacktraces.

The reason for this, is the "getCause()" implementation in the
RethrowableException, or rather, that this "nested Exception" is
retrofitted to make it "forward compatible" with java 1.4 by implementing
getCause(), but that the rest of the class doesn't take this into
consideration. The result is that one get -two- chaining mechanisms on
top of each other: RethrowableException faithfully chains the exceptions,
but then java 1.4 ALSO does this, seen by the "... 127 more" multiple
croppings of the stacktraces.

The included file is a quick adaption of my own implementation of the
"NestedException" as I called this thing. It uses introspection to see if
we're on a 1.4 platform, and if so, uses the native chaining support by
invoking the corresponding super-methods, while if not, we do chaining
ourself.
  Btw; I simply included the entire file, since basically all lines are
different and no other files are affected. Also, my editor reformats the
entire file. I assume that if you chuck it into your editor (IDEA, is
it?!), it is reformatted back to the WM-style?

However, the Exception hierarchy in WebMacro was a bit too complicated for
me to decipher within the small timeframe I had to submit this. Would it
be possible for you folks to just -test- this thing and se if it behaves?
(I must admit that I haven't got any projects using "WM2.0" at this time,
since I can't use cvs-code in such projects..)
  In particular, I didn't understand quite the "setContextLocation" method
which is present a couple of places (The one in WebMacroException is
weird: it checks the cause, and the root cause, but doesn't do anything
with any Exceptions which happens to be inbetween), and also 4 Exceptions
that inherit from Rethrowable overrides getMessage() - which seems to
partly destroy the chaining mechanism for the message, and/or put the
contextLocation info at the wrong place (typically at the end), instead of
where it should have gone.
  I believe that this could be redone quite nicely by instead -modifying-
the message in the RethrowableException (which now is stored locally too,
to handle the chaining), or drop the Rethrowable, and instead make
WebMacroException nested, and let that one have a method
"getContextLocation" which returns the value that was set previously, or
null if none. This latter idea would be "correct" in my view.

Well..

It would have been nice to kill of the lenght of those stack traces, and
get them more legible.

Regrads,
Endre.