Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Posting-Version: version B 2.10.1.chuqui 4/7/84; site apple.UUCP
Path: utzoo!watmath!clyde!burl!ulysses!bellcore!decvax!decwrl!sun!idi!apple!lsr
From: lsr@apple.UUCP (Larry Rosenstein)
Newsgroups: net.lang.mod2
Subject: Re: Exceptions
Message-ID: <19175@apple.UUCP>
Date: Thu, 13-Feb-86 12:23:54 EST
Article-I.D.: apple.19175
Posted: Thu Feb 13 12:23:54 1986
Date-Received: Sat, 15-Feb-86 02:36:41 EST
References: <913:manis@cs.ubc.cdn>
Reply-To: lsr@apple.UUCP (Larry Rosenstein)
Organization: Advanced Development Group, Apple Computer
Lines: 38

In article <913:manis@cs.ubc.cdn> writes:
>
>Exceptions, by their very nature, are global. One signals an exception, and
>any module in the system (or at least in the dynamic execution history of
>the program) can catch them. As a result, two modules may have different
>ideas on what to do with a given exception. Thus, there are very good 
>program structuring arguments against extensive use of exceptions. 
>

Not necessarily true.  

The CLU exception mechanism is local; if a procedure raises an exception,
only its caller can handle it.  If the caller does not handle it, the
exception is converted into a generic 'failure' exception, which will be
propagated up another level (and so on).  

The reason for this is modularity; a routine should not have to know about
exceptions that could be generated several levels of calls deep.  This is
in keeping with the CLU programming methodology that the internals of a
module are hidden from users of the module.  

The language provided a convenient way to pass an exception up a level, but
you had to explicitly write this.  Non-local exception mechanisms are
convenient because you do not have to explicitly pass exceptions on to your
caller if you don't care about them.

I have implemented a setjmp/longjmp kind of mechanism for the Pascal we use
(on top ofthe language), and found it to be very useful in handling errors.




-- 
Larry Rosenstein
Apple Computer

UUCP:  {voder, nsc, ios, mtxinu, dual}!apple!lsr
CSNET: lsr@Apple.CSNET