Error derived from Exception is WRONG, DAMNIT

[Sean Kelly]

== Quote from Yigal Chripun (yigal100 at gmail.com)'s article
> 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.

Assuming that a write actually occurred at that location, if the location were in dynamic memory it
would be technically possible to determine whether the written location was an allocated block or if it
was an empty/unallocated block.  Assuming it's the latter, the program is still in a valid state and may
continue.  This obviously wouldn't be the norm, but for some applications I might actually consider
doing this and recovering if possible.

> 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.

I think it depends.  Let's say that this is an application that repeatedly polls some external sensor and
passes the readings to an event handler.  The event handler only accepts a range of values and tests the
input parameters against this range within its "in" clause.  Let's further assume that it's not crucial for
every sample to be processed--say it's a temperature sensor and occasional samples may be thrown
out so long as a valid sample is obtained within a specific interval.  In this instance, a precondition
failure should not cause the system to fail--the system is in a valid and recoverable state, and the bad
sample could be thrown out and another obtained.  But it's possible that the event code could have
come from a third party where this behavior could not be altered, and performing the range check
before calling the event may not be possible if this is a virtual call to any one of a collection of events
(speaking of which--will we ever get inheritable pre/post-conditions like it says in the spec?).

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

It does as of the last Tango release.  A third-party plug-is is still required to actually generate the trace,
but it's not unlikely that we'll bundle these libraries in a future release.  That said, I think there are valid
reasons why tracing may not be preferable.  For one thing, generating a stack trace causes a noticeable
application slow-down, at least with flectioned.  Unless the trace will be displayed to the user, there's
really no reason to have them.


Sean