cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Leo Sutic" <leo.su...@inspireinfrastructure.com>
Subject RE: [VOTE RESULTS] Make ProcessingException extend CascadingRuntimeException
Date Tue, 20 Apr 2004 12:26:23 GMT


> From: Ugo Cei [mailto:u.cei@cbim.it] 
> > Therefore, ProcessingException should really be ProcessingError - 
> > since you're not expected to recover from it. Or extend Throwable 
> > directly.
> 
> Well that's more radical than my proposal! You won't catch it even if 
> you do "catch(Exception e)".

That's the point. A ProcessingException means that all elements of the
pipeline should just *stop*. They shouldn't try to recover (IoC),
proceed
(IoC) or try some backup solution (IoC again). Just stop, exit, and let
the Processor/sitemap logic handle it.
 
> I warn you that even Sun is not sure about what constitutes 
> an Error, as in the Javadoc it says:
> 
> "An Error is a subclass of Throwable that indicates serious problems 
> that a reasonable application should not try to catch.

I think that fits ProcessingException just fine.

The JavaDoc talks about "application", but you should understand this
in the proper context. If your code is a Cocoon component, then you
should read
this as: "An Error is a subclass of Throwable that indicates serious
problems 
that a reasonable Cocoon component should not try to catch."

I.e. the meaning of "application" is highly context-dependent. What we
have done is to create an application environment - call it Cocoon OS if
you want - where you run web applications consisting of components. Just
because you don't launch something from the command line doesn't mean
that
it isn't an application.

/LS


Mime
View raw message