cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Christopher Oliver <res1c...@verizon.net>
Subject Re: Cocoon Stack Traces
Date Mon, 12 Jan 2004 16:56:28 GMT
Sylvain Wallez wrote:

>
> Mmmh... if we push and pop stack frame indications, isn't it enough to 
> build a debugger?
>
> The runtime part of the debugger can be a optional listener in 
> add/popStackFrame which suspends the execution when a breakpoint is 
> encountered (detected using the stack element's location).
>
> And we can also associate an additional object to a StackTraceElement 
> that will give access to the variables in the element's scope. This 
> will be e.g. an InvokeContext for the TreeProcessor or a 
> [JXPath|Jexl]Context for JXTemplate. This allows the debugger do 
> display and even modify the variables that drive the current request's 
> execution.

Without getting into all the details, I think a proper API for a global 
debugger would require quite a bit more infrastructure than what you're 
suggesting. Also with the fast edit - reload - test cycle provided by 
Cocoon, "println()" style debugging seems to work quite well. A 
source-level debugger is mainly required when the development turnaround 
cycle is long (e.g. J2EE apps). For example, although Rhino has a 
JavaScript debugger, I rarely use it because println() debugging is 
usually more efficient.

Regards,

Chris


Mime
View raw message