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.
