cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Ugo Cei <u....@cbim.it>
Subject Re: Restating the Exception Problem (was Re: [VOTE] Make ProcessingException extend CascadingRuntimeException)
Date Fri, 16 Apr 2004 14:21:41 GMT
Berin Loritsch wrote:
> The core problem that the proposed vote was trying to solve was to 
> remove the need to catch a ProcessingException if we are merely going to 
> log and rethrow it.

Yes.

> Does the ProcessingException allow you to store any clues as to the type 
> of error handling we need (i.e. HTTP 500 error message, HTTP 404 error 
> message)?  The answer is no.  It does provide some extra code to output 
> a better error message though.

The answer is (theoretically) yes. The ProcessingException probably 
wraps the original exception, so you can retrieve it. However, if the PE 
is wrapped in a SAXException, which maybe is wrapped in something else, 
then it all becomes more difficult.

> So what is the best approach?  If we remove the ProcessingException,
> then we now have a backwards incompatible change.  The old components 
> compiled against old interfaces won't load because there is no 
> ProcessingException in the classpath.  That is clearly not the best 
> approach.

Of course, not.

> If we make ProcessingException a RuntimeException, then we 
> maintain backwards compatibility, and the need to declare the exception. 
>  Old precompiled code will still work, but if you recompile against the 
> new interfaces with no declared ProcessingException then you will have 
> an upgrade problem.

This if you remove the "throws ProcessingException" clause, but we won't 
necessarily.

> a more serious issue.  You cannot go by the type of exception alone.  By 
> allowing the ProcessingException to have this additional information 
> embedded, the Sitemap can better handle creating more accurate error pages.

I'm confused here. Doesn't it already have it embedded?

	Ugo


Mime
View raw message