Path: utzoo!utgpu!water!watmath!clyde!att-cb!att-ih!pacbell!ames!ncar!gatech!hubcap!ncrcae!ncr-sd!ncrlnk!ncrday!psldev!bruce
From: bruce@psldev.Dayton.NCR.COM (bruce frederiksen)
Newsgroups: comp.lang.c++
Subject: Re: Proposal for Exceptions for C++
Message-ID: <110@psldev.Dayton.NCR.COM>
Date: 31 Mar 88 16:20:31 GMT
References: <8180006@eecs.nwu.edu> <2229@phoenix.Princeton.EDU> <837@cresswell.quintus.UUCP>
Reply-To: bruce@psldev.Dayton.NCR.COM (Bruce Frederiksen)
Organization: Systems Engineering - Retail
Lines: 67

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

You've offered a solution to the stack overflow problem.  Your other
example, addressing non-existent memory, is one that I could use in a
project I'm working on here.  What I want to do is dynamically allocate
shared memory blocks that are used as shared heap space by several
processes.  When one process finds the heap exhausted, he creates a new
shared memory block (much like malloc doing an sbrk), attaches it,
initializes it and allocates his whatever.  He then chains this new
whatever to the shared list of whatevers that these processes are using.

Now another process takes control and starts reading down this list and
jumps off the end into the new shared memory block that he hasn't attached
yet.  Easiest way to handle this would be to have an exception handler in
each process to handle "addressing non-existent memory".  It just attaches
the new shared memory block and then returns back to the program as if
nothing had happened.

On a whole, I don't think that an exception mechanism should be built into
the language.  Any exception mechanism can be built in C++ to do whatever
you or I or anybody else might want except for two things:

	1. The standard setjmp/longjmp routines don't execute destructor
	   functions for objects in the intermediate (aborted) functions.

	2. (as you have said) Numerical exceptions (divide by 0, overflow,
	   underflow) are not reported in C.  You could write protected
	   numbers with operators that check for these things, but it may
	   not be as efficient as it could be when there is hardware
	   support for these.

I think that the first problem is at the real crux of exception mechanisms.
Once it is solved, exception mechanisms in the form of libraries can be
written without cluttering the language.  Then if you are not happy with
how I've implemented my exception mechanism you are not forced to use it.

One solution to the first problem might involve using two parallel stacks:
one for objects with destructors and one for everything else.  Then the
longjmp can fire up the destructor functions of all the objects in the one
stack (down to the function being returned to) without worrying about all
of the other clutter in the stack.  This assumes that the destructor
function and length of any object on the stack can be determined given just
its address.  Virtual functions handle this just fine.  So if you're
willing to live with virtual destructors and length functions this can all
be done in C++ without changing the language.

If anybody else has a solution to the setjmp/longjmp problem, I'd like to
hear it.

-bruce.frederiksen@Dayton.NCR.COM
 NCR Corp, SE-Retail, Dayton