I change my non-binding vote to -1.
Motivation:
When you have a block of code that uses other modules, you often end up doing:
try { ... } catch (Exception e) { // Whatever the cause, it didn't work. throw new MyException (e); }
Since RuntimeException isa Exception, this will catch and wrap RuntimeExceptions as well.
As it catches ProcessingException now.
This sort-of defeats what we're trying to achieve with ProcessingException, which is to make it bypass all wrapping and so on and go directly to the bottom of the stack.
Therefore, ProcessingException should really be ProcessingError - since you're not expected to recover from it. Or extend Throwable directly.
Well that's more radical than my proposal! You won't catch it even if you do "catch(Exception e)".
I warn you that even Sun is not sure about what constitutes an Error, as in the Javadoc it says:
"An Error is a subclass of Throwable that indicates serious problems that a reasonable application should not try to catch. Most such errors are abnormal conditions. The ThreadDeath error, though a "normal" condition, is also a subclass of Error because most applications should not try to catch it."
But then you see javax.xml.parsers.FactoryConfigurationError extends Error.
Really makes you wonder whether all this mess about Throwable/Error/Exception/RuntimeException does make any sense.
In the end, it just reinforces my conclusion: checked exceptions suck. Gosling had good intentions but, as they say, the road to hell is paved with good intentions. They do not work in practice, as nobody will ever agree as to what constitutes a programming error, an abnormal condition or a recoverable cause.
I am pretty sure that if we forgot about checked exceptions, we'd have less verbose code, easier to understand and maintain. I am also sure that it will take some time before this "heresy" becomes mainstream.
Ugo
