Sylvain Wallez wrote:
Christopher Oliver wrote:
I started looking into how I could get a meaningful stack trace (with location information) spanning (possibly nested) invocations of the sitemap, flowscript, and JXTemplateGenerator.
<snip>
WDYT?
/me thinks it's great!
Some low-level remarks, however:
- we need a "popStackFrame()" method, since once a component has been executed successfully and execution continues in its following siblings, it should no longer appear in the stack trace
The idea is that this stack trace is created during exception processing:
try {
do whatever
} catch (Exception e) {
Cocoon.addCocoonStackTrace("failed to do whatever", "comp", "method", uri, line, column);
throw e;
}
Thus, during normal processing there is no overhead. That's why there's no popStackFrame().
- is the "message" parameter really needed? It's only meaningful for the statement where the error occured, and will be present in the Java exception that is raised.
I guess you're right, but my thinking was that additional information about the call site could be useful. If there's no additional information you can just pass null.
- consequently, to minimize performance overhead, I think it would be better to pass a single StackTraceElement parameter (or "CocoonStackFrame"?), since these objects can be pre-allocated at script/template/sitemap load time and are immutable afterwards.
See above.
- I don't like much putting this on the "Cocoon" class. What about creating a "org.apache.cocoon.util.debug" package holding the various classes that will certainly follow this first enhancement. I'm thinking to a global debugger that may be built using these stack frames.
This approach was only designed to support exception reporting, not to support debug tracing or to develop a debugger. For those purposes a different design is required.
Regards,
Chris
