cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Torsten Curdt <>
Subject Re: Cocoon Stack Traces
Date Tue, 13 Jan 2004 10:39:23 GMT
>>>>> 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.
>>>> I do the same for flowscript. But how can we insert a println() in a 
>>>> sitemap?
>>> How about adding a "message" attribute to ProcessingNode, e.g:
>> I like this very much!
> I don't like this and find it hacky. Using println in the flowscript is 
> a useful technique and as I said I use it. But introducing official 
> println equivalents all over the place will lead to floods of messages 

I'd like to second that.

Besides I think we are mixing debugging with error reporting.

For error reporting we don't necessarily need a println.
As long as the exception carries all needed information we
can display something useful inside the browser and/or the log.

This came up once at a Cocoon Stammtisch in Frankfurt when we
were talking about XSP debugging and error reporting: we could
introduce an exception that swallows SAX events so we can store
semantically useful information inside the exception. The events
could then be put back into the error pipeline. A stylesheet could
to the rest.

...or we have a couple of specific exceptions that have a toSAX()

Anyway ...I'd prefer not to clutter the sitemap with println


View raw message