Re: Structured exception information

"Dmitry A. Kazakov" <mailbox@xxxxxxxxxxxxxxxxx> wrote in message
news:s0prxwrhxfj1.1r5zzccgpzy2.dlg@xxxxxxxxxxxxx
On Tue, 16 Jan 2007 17:50:46 GMT, Jeffrey Carter wrote:

Dmitry A. Kazakov wrote:

procedure Foo raises Foo_Error; -- Compile error!

Generally, subprograms should raise exceptions because of precondition
violations. If the preconditions are met, the subprogram should not
raise an exception (barring things that are beyond the developer's
control, such as running out of memory). So it would be better to
associate a subprogram with a list of preconditions with the exception
raised if each is violated:

....
Totally disagree.

A precondition violation is not an exceptional state, it is a bug. Bugs
fundamentally cannot be handled within the same program. This "exception"
should propagate in the visual debugger and further into the head of the
code maintainer, If you want.

The difference becomes obvious if you consider that there might well be
valid program states corresponding to the end of a file. But there cannot
be any valid and consistent state in which there would exist x such that
cosh(x)<1.

Therefore their handling strategies are quite different as well. Bugs
propagating exceptions is the worst debugging nightmare. A precondition
violation shall stop immediately to prevent further harm and to make a
inspection possible. Exceptions are just a method of flow control.

Yikes. If a precondition failure can be detected statically (i.e. at compile
time), then surely you are right.

But most of them cannot. And I have a lot of software that shouldn't stop
just because it has a bug. For example, my mail server shouldn't stop
handling mail just because a bug was encountered (and it certainly has had a
few bugs, especially in the spam filter): I want to write the failure into a
special log, save the offending message if possible, reinitialize the task
to a starting state, and continue. Anything else would stop the flow of
mail.

Surely there are systems where the best response to a bug is a full stop,
but there are many for which that would be silly. If the airplane or rocket
software shuts down because a bug, at best you'll have vehicle loss (and at
worst, loss of life).

In any case, you can't draw a hard line between what is a bug and what is
some other sort of error: it can even depend on intended use. A Find routine
that doesn't find anything could be an error or could be expected -- and we
don't have different otherwise identical routines for this purpose.

Randy.


.

Relevant Pages

  • Re: Structured exception information
    ... subprograms should raise exceptions because of precondition ... A precondition violation is not an exceptional state, ...
    (comp.lang.ada)
  • Re: Structured exception information
    ... associate a subprogram with a list of preconditions with the exception ... A precondition violation is not an exceptional state, it is a bug. ...
    (comp.lang.ada)
  • Re: contracted exceptions
    ... No, if the precondition was violated by the caller, then how this ... How is the callee supposed to handle the contract violation? ... Right, this is why continuation in any form, including raising exceptions, ...
    (comp.lang.ada)
  • Re: GNAT packages in Linux distributions
    ... exceptions" style leads to the universally applicable precondition ... typed predicates, supported by tools, than nothing. ... end loop; ...
    (comp.lang.ada)
  • Re: JavaScript error with onChange event handler -- FireFox 1.5
    ... That looks like the old autocomplete bug, but it was fixed in Firefox ... You code runs w/o exceptions on test machines. ... Also this bug leads to an exception, not to an error: ... script execution is not aborted. ...
    (comp.lang.javascript)