cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Berin Loritsch <>
Subject Restating the Exception Problem (was Re: [VOTE] Make ProcessingException extend CascadingRuntimeException)
Date Fri, 16 Apr 2004 13:28:35 GMT
I am a little confused, it seemed like the direction of the discussion 
on checked vs. unchecked exceptions was leading us down the path of this 
vote.  I realize that there are valid points on both sides of the issue, 
so for my benefit and the benefit of everyone, I am going to try and 
restate the problems trying to be solved so that we at least have a 
common understanding.  (I'm not there yet so it is probably more for my 

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.

The core problem that Nicola is concerned about is letting Cocoon
automatically handle the specific types of issues that it might need--in 
essence removing the need for any type of Cocoon specific exception.

The goals are the same: to make it easier to write the components and 
blocks and clean up the code.

Looking at the core components (Generator, Transformer, Serializer),
they declare a set of exception types that can be thrown:

Generator->IOException, SAXException, ProcessingException
Transformer->SAXException, IOException, ProcessingException
Serializer->IOException, ProcessingException

All of these can throw whatever exceptions are necessary.  If any 
exception is thrown, then the sitemap needs to handle it appropriately.
The next question is what is done differently in all these cases?
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.

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.  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.

Of course there is another solution which is to add some information to 
the ProcessingException that would give a better semantic clue to the 
Sitemap the true nature of the problem and how best to translate that 
into the error message pages.  For example, a SQLException and an 
IOException might signal that a resource is not found, or that there is 
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.

Of course, if we declare all these exception types in the interfaces,
we should not have to catch them in the sitemap components.  They should 
be able to be handled in other ways.

If we declare a general throws clause of any Exception type, then we can 
minimize the number of necessary catches completely.

If changing the ProcessingException to a RuntimeException will help 
initially down this road, then I am all for it.

View raw message