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
