Path: utzoo!mnetor!uunet!husc6!think!ames!lll-tis!mordor!sri-spam!sri-unix!quintus!ok
From: ok@quintus.UUCP (Richard A. O'Keefe)
Newsgroups: comp.lang.c++
Subject: Re: Proposal for Exceptions for C++
Message-ID: <837@cresswell.quintus.UUCP>
Date: 30 Mar 88 08:00:23 GMT
References: <8180006@eecs.nwu.edu> <2229@phoenix.Princeton.EDU>
Organization: Quintus Computer Systems, Mountain View, CA
Lines: 38

In article <2229@phoenix.Princeton.EDU>, lgy@pupthy2.PRINCETON.EDU (Larry Yaffe) writes:
> 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]
>     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.

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

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

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.