Path: utzoo!mnetor!uunet!husc6!bloom-beacon!mit-eddie!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: <2243@phoenix.Princeton.EDU>
Date: 30 Mar 88 16:43:28 GMT
References: <8180006@eecs.nwu.edu> <2229@phoenix.Princeton.EDU> <837@cresswell.quintus.UUCP>
Sender: news@phoenix.Princeton.EDU
Reply-To: lgy@pupthy2.PRINCETON.EDU (Larry Yaffe)
Organization: Physics Dept, Princeton Univ
Lines: 63

In article <837@cresswell.quintus.UUCP> ok@quintus.UUCP (Richard A. O'Keefe) writes:
>In article <2229@phoenix.Princeton.EDU>, lgy@pupthy2.PRINCETON.EDU (Larry Yaffe) writes:
>>     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.
>
>This is a very strong requirement.  How would you handle stack overflow
>in such a scheme?  (Ok, you could reserve a handler stack, but what do
>you do if the handler returns?)  In general, there are lots of exceptions
>which cannot sensibly be continued.  Another example:  addressing
>non-existent memory.

    Certainly there are exceptions which cannot sensibly be continued.
However, since there are also exceptions which CAN sensibly be continued,
I would greatly prefer any exception handling language extension to
permit continuation.  I regard your example of `non-continuable'
stack overflow with some amusement - since I view this as excellent example
of an exception which should be continuable (if, of course, the handler
can first dynamically extend the stack).  Some operating systems do this
all the time; I would like to be able to do the same thing cleanly and
easily within a good progarmming language.

>>  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.
>>     This sort of approach is possible with UNIX signals...

>Er, no.  Unless UNIX==BSD.  There is no portable way for a System V
>program to find out what sort of floating-point error it got.  (A SIGFPE
>might even mean _integer_ divide by zero.)  There are also UNIX systems
>providing IEEE floating-point arithmetic where underflows and overflows
>and such don't give you exceptions.

    Perfectly true.  That's why I'd like to be able to do this solely within
C++.

>> But any exception scheme which prohibits this usage seems (to me) to be
>> like a two-legged chair - essentially useless.

>ADA is "essentially useless"?  I must remember that.

    While my analogy may be just slightly exaggerated (:-), the important
qualifier was "to me".  And yes, PERSONALLY, I regard Ada as
"essentially useless".  Your mileage may vary.

>PL/I has this sort of handling scheme; in order to give you a way of
>trying to repair errors so that you could continue, PL/I has ever so
>many ON<thing> pseudo-variables.  Try it, you'll hate it.

    Your're quite right - nearly everything I know about PL/I convinces me
I don't want to use it.  But that doesn't mean there arn't good ideas
floundering in that swamp of a language.

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