Error derived from Exception is WRONG, DAMNIT

[Sean Kelly]

== Quote from downs (default_357-line at yahoo.de)'s article
> Why is Error, in 2.0, _STILL_ derived from Exception?
> I understand that this has come up before, which makes it all the more confusing that it's _STILL_ not
fixed. And make no mistake, this isn't just a matter of semantics, but an actual bug causing actual
problems, such as unexpected crashes.
> Let's see, the only use of making unrecoverable Errors a *special case* of recoverable Exceptions
would be, um, if you wanted to catch unrecoverable Errors only ...
> Does anybody else see a problem with that statement? Like, that you're not supposed to catch
unrecoverable errors in the first place?
> The problem with this ordering is that you end up _accidentally_ catching unrecoverable errors, which
in turn leads to maybe not even noticing some critical error in debug mode, which in turn leads to
different behavior between debug mode and release mode, such as mysterious, unexpected
segmentation faults (say on Array Bounds Violation). I don't have to explain why this is a bad thing.
> Could this be changed? _Please_?
>  --downs, slightly agitated :)

I'm not sure I agree.  First, I think it's important to note that all Errors are Exceptions, so the inheritance
relationship makes sense.  Also, I feel that all throwable objects should be classified as Exceptions, so I
don't like the idea of having them both be siblings derived from Throwable.  Finally, while it may be
easy to catch and ignore Exceptions, I feel very strongly that this is bad programming practice.
Exceptions should never be caught and ignored--particularly at such a granularity.  I would prefer that
a library stick to its guns and inspire a change in programmer mindset than to make allowances for such
mistakes.


Sean