Path: utzoo!mnetor!uunet!husc6!bloom-beacon!tut.cis.ohio-state.edu!rutgers!princeton!phoenix!pupthy2!lgy
From: lgy@pupthy2.PRINCETON.EDU (Larry Yaffe)
Newsgroups: comp.lang.c++
Subject: Re: Proposal for Exceptions for C++
Message-ID: <2229@phoenix.Princeton.EDU>
Date: 29 Mar 88 21:50:58 GMT
References: <8180006@eecs.nwu.edu>
Sender: news@phoenix.Princeton.EDU
Reply-To: lgy@pupthy2.PRINCETON.EDU (Larry Yaffe)
Organization: Physics Dept, Princeton Univ
Lines: 43
Summary: Simple "resume" inadequate

In article <8180006@eecs.nwu.edu> morrison@eecs.nwu.edu (Vance Morrison) writes:

>A PROPOSAL FOR ADDING EXCEPTION HANDLING TO C++

	[fairly reasonable proposal deleted]

>	SO WHAT DO YOU THINK????
>
>					Vance Morrison
>					morrison@accuvax.nwu.edu
>					morrison@nuacc.bitnet

    As far as I can tell, this proposal for exception handling
(as well as exception handling in many other languages) fails to allow
a very basic form of exception handling that I regard as essential:
the ability for an exception handler to return control to the point
at which the exception was (first) raised and NOT disturb the normal flow
of control.  A simple example from real life involves the following:

    Given a large (numerical analysis) program, determine how many times
a floating point underflow occurs (for particular input) while simultaneously
preserving the usual handling of underflows: setting the result to zero
and continuing.  The desired approach: writing a single underflow exception 
handler which increments a counter, zeros the result, and returns control
to the point where the underflow occured, and then hanging this exception
handler on the top level main routine.  Aborting the calculation at the
first underflow is unacceptable, as is decorating each and every line of
the program with "catch UNDERFLOW; <increment counter>; resume" or some
such variant.

    This sort of approach is possible with UNIX signals, but a good
exception handling extension to the language should surely make resorting
to 'signal' unnecessary.  Obviously, allowing an exception handler to return
to the point where the exception was raised means that one cannot unwind
the call frame looking for a handler, and hence complicates the implementation.
But any exception scheme which prohibits this usage seems (to me) to be
like a two-legged chair - essentially useless.

------------------------------------------------------------------------
Laurence G. Yaffe			lgy@pupthy.princeton.edu
Department of Physics			lgy@pucc.bitnet
Princeton University			...!princeton!pupthy!lgy
PO Box 708, Princeton NJ 08544		609-452-4371 or -4400