Error derived from Exception is WRONG, DAMNIT

[Yigal Chripun]

Sean Kelly wrote:
> == Quote from Yigal Chripun (yigal100 at gmail.com)'s article
>   
>> My point is that errors have the same relation to exceptions. There is
>> additional functionality that  exceptions provide ( you can catch them
>> and do stuff) which are not part of an error's interface. Errors should
>> represent unrecoverable situations where the program must terminate.
>> catching an error is, as downs said, a BUG.
>>     
>
> So the problem then becomes which errors to classify as non-recoverable.  Particularly in a systems
> language like D, I would be hesitant to dictate that almost any errors must necessarily terminate the
> program.  Consider an array bounds error.  This is a system-generated error that clearly indicates a
> program flaw, and yet the program is still in a valid state.  The same could be said of other errors as
> well.  When considering adding an Error class to Tango, I ended up deciding that there were very few if
> any errors that I felt were non-recoverable in every program where they may occur.  Ultimately, it seems
> to make more sense to leave the decision to the programmer to determine recoverability.  If the
> programmer really wants to generate an error intended to be unrecoverable, he can always throw an
> Object anyway.  Sure, Objects can still be caught, but I think few programs actually do this (outside the
> catch{} statement anyway).
>
>
> Sean
>   
What you describe is already partly solved in Tango.
 There are callback functions that allow you as a systems programmer to
change the default handler for such errors. so you already realized that
these errors and asserts shouldn't be handled by a regular try catch block.

to address your example:
how can you state that a program with an array bounds error is in valid
state? on the contrary, the program accessed an area of memory which it
didn't supposed to access. either it read garbage data or worse, it
wrote at a random memory location possibly overriding other info stored
there. i.e. it is not in a valid state. in C that's usually results in a
segmentation fault, which needs to be fixed at debug time. in a running
program, would you really want to "catch" such an error and try to
recover from it? most likely not.

I think that downs' solution is a good one where exception inherits from
error . thus, I could catch general Exception objects without worries,
and if i need to handle errors in a different way, I can change
appropriate handlers.
By default, however, asserts and unrecoverable errors must terminate the
system. they indicate errors in system logic (i.e. bugs) and should be
handled while debugging. in production you can't really recover from an
error in system logic.

also, I think that the global "Exception" class should come with tracing
enabled by default. why would anyone need an exception mechanism without
tracing?

--Yigal