Restating the Exception Problem (was Re: [VOTE] Make ProcessingException extend CascadingRuntimeException)

[Berin Loritsch <bl...@d-haven.org>]

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

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.

Re: Restating the Exception Problem (was Re: [VOTE] Make ProcessingException extend CascadingRuntimeException)

[Berin Loritsch <bl...@d-haven.org>]

Ugo Cei wrote:

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

only by exception heirarchy.  For instance, the 
ResourceNotFoundException is a Processing exception, which provides the 
hint that it is a 404 error.

Now it would be just as easy to allow the embedding of an error code so 
that we can handle any arbitrary issue.  Another example is the 403 
authorization error.  I don't think we have a specific exception for that.

According to what I see:

http://cvs.apache.org/viewcvs.cgi/cocoon-2.2/src/java/org/apache/cocoon/ProcessingException.java?view=markup

There is no get/set error code for the exception.  Adding one is 
backwards compatible, and then using the error code is something that 
can be done in the sitemap.

Our exception inheritance structure would allow automatic setting of the 
appropriate error code for that exception type so you don't loose the 
convenience, but you can still handle error codes that aren't 
specifically handled right now.

Re: Restating the Exception Problem (was Re: [VOTE] Make ProcessingException extend CascadingRuntimeException)

[Ugo Cei <u....@cbim.it>]

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