cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Stefano Mazzocchi <>
Subject Re: Should we catch java.lang.Error? (was RE: XMLForm and sitemap problem (fwd))
Date Thu, 08 May 2003 20:06:50 GMT
on 5/8/03 7:30 AM Bruno Dumon wrote:

> On Thu, 2003-05-08 at 12:20, Stephan Michels wrote:
>>I can reproduce the blank page in case of a java.lang.Error. So,
>>there is the best place to handle them? In the pipeline implementation?
>>Or should they be handled by the container?
> I would treat them like exceptions, so that something meaningful can be
> done with them in the handle-errors.

I totally agree! All throwables should be seen by the handle-errors

> Or at least we should catch them in the CocoonServlet class, and send a
> 500 to the browser.
> As background info, here is what the javadoc for the Error class says:
> "An Error is a subclass of Throwable that indicates serious problems
> that a reasonable application should not try to catch. Most such errors
> are abnormal conditions. The ThreadDeath error, though a "normal"
> condition, is also a subclass of Error because most applications should
> not try to catch it. 
> A method is not required to declare in its throws clause any subclasses
> of Error that might be thrown during the execution of the method but not
> caught, since these errors are abnormal conditions that should never
> occur."

Yes, but cocoon is a framework, so it's the pipeline components that
should not try to catch it, but the framework *must* be informed about
it so that framework administrators can do something about it
(presenting a 500 for an OutOfMemory could be very bad marketing for us)


View raw message