Path: utzoo!mnetor!uunet!husc6!encore!pierson
From: pierson@encore.UUCP (Dan Pierson)
Newsgroups: comp.lang.c++
Subject: Re: Proposal for Exceptions for C++
Message-ID: <2885@encore.UUCP>
Date: 7 Apr 88 15:42:10 GMT
References: <22999@bbn.COM>
Sender: news@husc6.harvard.edu
Reply-To: pierson@encore.UUCP (Dan Pierson)
Distribution: na
Organization: Encore Computer Corp, Marlboro, MA
Lines: 50
Keywords: Avalon, C++, exceptions

In article <22999@bbn.COM> dwaitzma@vax.BBN.COM (David Waitzman) writes:
>In nnsc.nsf.net pub/exceptions.PS (available via anonymous ftp) is a
>(drafty) paper (in postscript) on adding exceptions to a language
>built upon C++: Avalon.  The paper also examines adding exceptions to
>C++ directly.  Some of the ideas presented in the paper have been
>discussed with (the) Bjarne.

Your proposal is almost the best so far.  It certainly does the best job
of integrating exceptions into the C++ class system.  However, there is
one part of the proposal which I strongly dislike: exceptions are only
propogated a single call level.  This causes code written using
exception handling to be almost as verbose, hard to read, and hard to
maintain as code using special return values.  The biggest possible win
with this approach is that instead of having to follow every call which
wishes to check errors with a block of error handling code, you have to
follow every block which wishes to check errors with a block of error
handling code.  Much of this code will include something like:

	...
	default: ex->raise();
	...

In fact, in many cases that may be the entire contents of the exception
clause! 

Consider the following case: We're about to perform an atomic action of
some sort.  The top level code sets up the atomic block in some way and
calls one or more lower level routines to perform the action.  These
routines then call other routines, etc.  Several call levels down a
routine runs out of a critical resource, say memory or disk space.  In
the context of this application the correct thing to do is back out the
current action and let the top level routine try and get more resource,
say by cleaning up or asking the user for help.

What I'd like to do is have all the lower level routines proceed with no
knowledge of this possible problem __except__ for providing finalization
methods which undo all of their work (which should only be resource
allocation at this level).  The exception would propogate up to the
handler in the top level routine, cleaning things up as it goes, and the
top level handler would then try to get more of the resource and try the
action again (or raise its own exception).

With your proposal, every single routine would have to have an exception
block which explicitly re-raised all exceptions.  This would add to the
code bulk, thus camouflaging the local algorithms to no benefit.
-- 

In real life: Dan Pierson, Encore Computer Corporation, Research
UUCP: {talcott,linus,necis,decvax,ihnp4}!encore!pierson
Internet: pierson@multimax.arpa