Path: utzoo!utgpu!water!watmath!watmsg!pabuhr
From: pabuhr@watmsg.waterloo.edu (Peter A. Buhr)
Newsgroups: comp.lang.c++
Subject: Re: Proposal for Exceptions for C++
Message-ID: <17935@watmath.waterloo.edu>
Date: 31 Mar 88 11:56:14 GMT
References: <8180006@eecs.nwu.edu> <2229@phoenix.Princeton.EDU>
Sender: daemon@watmath.waterloo.edu
Reply-To: pabuhr@watmsg.waterloo.edu (Peter A. Buhr)
Organization: U. of Waterloo, Ontario
Lines: 29

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

Now, you see, I don't consider this situation as an exception. PL/I
handles this using ON CONDITIONS, which are not exception, but
dynamically bound procedure calls. Exceptions alter the normal
prescribed flow of control in a program. All you want is to invoke a
user defined routine whenever an underflow occurs. Hence, the hardware
calls some routine when it discovers an overflow and you are allowed
to change which routine gets called. In PL/I, there is a essentially a
procedure variable called OVERFLOW (or something like that) which PL/I
initializes to a routine that prints an error message and then aborts
execution which might be done by raising an exception to alter the
flow of control to the system (PL/I does not do this, it just sets
fire to your program and walks away). You are allowed to reassign the
value of this procedure variable to your own routine.  So you can
count the number of overflows and possible reset the erroneous value
to anything you like and then return back to the hardware to continue
execution. PL/I makes it all complex by using dynamic binding to determine
which procedure named OVERFLOW to executed, but that's another issue.