Error derived from Exception is WRONG, DAMNIT

[downs]

Sean Kelly wrote:
> == 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.
All Errors are Exceptions because we say so. This model has no inherent value except from the point of view of the current Phobos implementation.
It makes more sense, from a user POV, to say that Exceptions are special cases of Errors that can be caught.

> 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.
Neither did I suggest this; actually, my thought was Exception : Error :)

> 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.
What about cases where we just want to see if some operation succeeds, and if not, try something else instead, _regardless_ of the reason why it failed?
Also, I'd argue that such a change would not be for the better.
The whole *point* of Exceptions is that they are recoverable - if I want to catch and discard all of them, I don't want the compiler to give me moral lessons about error handling, I want it to *get the :bleep: out of my way and let me do what I want to do.*
Not crash and burn in release mode. :)


> 
> 
> Sean

 --downs