Re: Goto inside a call statement?

One of the reasons I don't like the exception handling features of
most other languages is that they don't even mention the possibility
of error locally. That is, if A calls B which then calls C, and an
exception occurs in C there will be no indication in the source
code of B that C's return will be to some handler in A. The
author of B might indeed be unaware that C might raise exceptions
that it doesn't handle itself. This causes hard to find problems
(since A might have a handler for the exception because of
a known possibility of the condition right there in A: the
handler has no notion of how to correctly handle problems
coming from C). I've seen these myself in several Ada codes.
Or, B might have some things it needs to deallocate or files
to close and be deprived of the opportunity because C didn't
return. I've seen that problem many times too.

All these are indicative of an incorrectly designed exception handling system. The only exception handling system that I know intimately - the one designed for VMS - provides exactly for those scenarios in a way that is reasonably easy to use.

And it still doesn't intermix
the code for proper operation of the program with code to
handle rare anomalies, nor does it require statements that
make redundant tests (*ALL* tests of return codes are redundant,
the procedure that returned them has already decided whether
the exception has arisen or not).

In this connection, making an exception handling facility available at all has significant performance implications on modern processors, which return codes do not have. Finding the proper balance is not easy. Do you want to pay for this, for instance, on every math library call, or would you rather handle it using NANs when and where required?

Note: most of the objections still seem to be coming from people
who regard exception handling as something that allows them
to "clean-up" before terminating. That should actually be a separate
feature (i.e. how should the program respond to a terminate signal?).
Exceptions should be used only for two purposes: 1) to correct
the problem so the program can continue running or 2) to refer the
decision about whether the problem is fatal to some other part
of the program.

Agreed.

Jan
.

Relevant Pages

  • Re: Try Finally...
    ... >the application's default exception handler, ... the records are traversed and the stack ... stopping the whole shebang at that point, and terminating the app. ...
    (comp.lang.pascal.delphi.misc)
  • Re: Thread Abort and Unhandled Exception Event
    ... event, not an exception handler. ... I might have called that a handler, ... that once the application is terminating, ... handler in the thread itself (that is, try/catch at the top of the thread ...
    (microsoft.public.dotnet.framework)
  • Re: More on Exceptions.
    ... no exception is ever thrown. ... Having determined the stream 'state' you then take appropriate action. ... as the exception handling is 'quarantined' within the ... int main ...
    (alt.comp.lang.learn.c-cpp)
  • Re: Exception handling in class: question
    ... >> practice for exception handling or should they be sprinkled through code ... you were hiding your question in Perl verbiage. ... > Only use it if the exception can't be otherwise anticipated. ... The first form traps run-time exceptions that would otherwise prove fatal, ...
    (comp.lang.perl.misc)
  • Re: count2.asm
    ... >> But seriously, without HLA's exception handling, it would have ... routine both end up checking for errors...the called routine checks for ... "general purpose handler" with catch the serious errors...if you want to ...
    (alt.lang.asm)