Termination vs. Resumption semantics for exceptions (was: Re: Exceptional Situations in Javascript)

Brendan Eich brendan at mozilla.org
Thu Mar 29 17:59:45 PDT 2007


On Mar 27, 2007, at 8:39 AM, Brendan Eich wrote:

> That ship sailed with Edition 3, sorry. The Java precedent weighed
> heavily on TG1 and we have never revisited. I wasn't involved much in
> ES3 (1998, mozilla.org creation), but I remember that we knew about
> the alternative approach, both from Lisp and from some ex-PARC Mesa
> folks at Netscape at the time. Shaver may remember more.
>
> Apart from the history, we haven't heard this request enough to pull
> our focus. Apart from TG1, the idea comes up in the context of
> debugger design, where it can be addressed outside of the language.

Here's the reference I was paraphrasing above (thanks to Andrew Myers  
for finding it):

http://www.daimi.au.dk/~beta/News/volume1996/news/10680.txt

Quoting at length:

 > 	Then, at the Palo Alto meeting in November 1991, we heard a
 > 	brilliant summary of the arguments for termination semantics
 > 	backed with both personal experience and data from Jim Mitchell
 > 	(from Sun, formerly from Xerox PARC). Jim had used exception
 > 	handling in half a dozen languages over a period of 20 years
 > 	and was an early proponent of resumption semantics as one of
 > 	the main designers and implementers of Xerox's Cedar/Mesa system.
 > 	His message was
 >
 > 		``termination is preferred over resumption; this is
 > 		not a matter of opinion but a matter of years of
 > 		experience. Resumption is seductive, but not valid.''
 >
 > 	He backed this statement with experience from several operating
 > 	systems. The key example was Cedar/Mesa: It was written by people
 > 	who liked and used resumption, but after ten years of use, there
 > 	was only one use of resumption left in the half million line
 > 	system -- and that was a context inquiry. Because resumption
 > 	wasn't actually necessary for such a context inquiry, they removed
 > 	it and found a significant speed increase in that part of the
 > 	system. In each and every case where resumption had been used
 > 	it had -- over the ten years -- become a problem and a more
 > 	appropriate design had replaced it. Basically, every use of
 > 	resumption had represented a failure to keep separate levels
 > 	of abstraction disjoint
 >
 > 	Mary Fontana presented similar data from the TI Explorer system
 > 	where resumption was found to be used for debugging only, Aron
 > 	 Insinga presented evidence of the very limited and nonessential
 > 	use of resumption in DEC's VMS, and Kim Knuttilla related exactly
 > 	the same story as Jim Mitchell for two large and long-lived
 > 	projects inside IBM. To this we added a strong opinion in favor
 > 	 of termination based on experience at L.M.Ericsson relayed to
 > 	us by Dag Bruck.
 >
 > 	Thus, the C++ committee endorsed termination semantics.

In JS debuggers I know, being able to catch exceptions in their throw  
contexts is very important. But the use-cases in production code just  
do not justify resumption semantics, IMHO. It entails dynamic scope  
-- just say no (I've repented! ;-).

/be

>
> /be
>
> On Mar 27, 2007, at 3:51 AM, P T Withington wrote:
>
>> Was any consideration given to adding the ability to handle
>> exceptions in Javascript the way they are handled in [Lisp](http://
>> www.nhplace.com/kent/Papers/Exceptional-Situations-1990.html)?
>>
>> In particular, I really miss the ability to handle an exception in
>> the exception context (as opposed to only after the stack has unwound
>> to a try block).  Compared to the DOM level 2 event handling,
>> Javascript exception handling seems weak.
>>
>>
>> _______________________________________________
>> Es4-discuss mailing list
>> Es4-discuss at mozilla.org
>> https://mail.mozilla.org/listinfo/es4-discuss
>
> _______________________________________________
> Es4-discuss mailing list
> Es4-discuss at mozilla.org
> https://mail.mozilla.org/listinfo/es4-discuss




More information about the Es4-discuss mailing list