Leo Sutic wrote:
> 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