Path: utzoo!utgpu!water!watmath!clyde!rutgers!gatech!bloom-beacon!athena.mit.edu!wesommer
From: wesommer@athena.mit.edu (William Sommerfeld)
Newsgroups: comp.lang.c++
Subject: Re: Questions for Bjarne
Message-ID: <2943@bloom-beacon.MIT.EDU>
Date: 13 Feb 88 23:06:13 GMT
References: <848@PT.CS.CMU.EDU>
Sender: daemon@bloom-beacon.MIT.EDU
Reply-To: wesommer@athena.mit.edu (William Sommerfeld)
Organization: Massachusetts Institute of Technology
Lines: 45

In article <848@PT.CS.CMU.EDU> dld@F.GP.CS.CMU.EDU (David Detlefs) writes:
>    I did have some slight reservations though: I'm familiar with
>exceptions only through my use of CLU and Common Lisp.  The proposed
>mechanism is semantically much closer to the Common Lisp
>catch/throw/unwind-protect mechanism than it is to the CLU scheme, in
>which you can only signal up to the caller, which must then handle the
>exception and resignal if you want it handled somewhere down the call
>stack.  Thus, an exception in CLU is like an "alternate return," and
>the exceptions that a procedure may raise are considered part of its
>type signature.  This seemed to me to offer more security than the
>Common Lisp (or setjmp) approach.  I realize that if a CLU-like scheme
>were to be adopted for C++ it would in some sense violate the spirit
>of the language, in that it would be denying the user access to
>functionality that could easily be available, but I think the issue
>should at least be thought about.

Having used CLU for a number of projects for courses here, I would say
that the exception handling system is so ``safe'' as to be virtually
worthless except as syntactic sugar; it is not significantly different
than returning error codes from the routines and checking all the
return values (although the implementation can be slightly faster in
the general case).  If an exception is not handled by the containing
procedure, it turns into a failure exception which propagates up the
stack.

[CLU uses a garbage-collected heap for everything, and has no concept
of a ``destructor'' for a type; thus, a lot of cases where you would
want to `unwind-protect' to free up storage that is locally allocated
just disappear; however, the presence of garbage collection imposes
some nasty performance penalties, especially in a virtual memory
environment]

There is no way in CLU to write a shell which, when some sort of
failure is detected, unwinds back to the shell prompt cleanly without
putting handling code at every intermediate level.

By the way, there is a distinct difference between the ``setjmp''
approach and the LISP approach: with setjmp, you _can't_ do an
`unwind-protect' around an arbitrary block of code unless you use some
sort of convention for dealing with the setjumps and longjumps.

					- Bill

"Syntactic sugar causes cancer of the semicolon"
				-- Alan Perlis