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

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

# Brendan Eich (18 years ago)

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

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! ;-).

# P T Withington (18 years ago)

On 2007-03-29, at 20:59 EDT, Brendan Eich wrote:

In JS debuggers I know, being able to catch exceptions in their throw contexts is very important.

That's exactly the use case I have in mind, so, maybe there could
just be some introspection facility that supported that particular
use case?

# Lars T Hansen (18 years ago)

On 3/31/07, P T Withington <ptw at pobox.com> wrote:

On 2007-03-29, at 20:59 EDT, Brendan Eich wrote:

In JS debuggers I know, being able to catch exceptions in their throw contexts is very important.

That's exactly the use case I have in mind, so, maybe there could just be some introspection facility that supported that particular use case?

Most (all?) of the major implementors are currently providing (or are in the process of providing) debugging tools for their user base. It's true that the functionality and quality of these tools are variable, and that good third-party tools might provide welcome uniformity and quality to the field, if we could define a debugging API that is sufficiently rich for advanced debugging. Having done that (while I was working at Opera), however, it seems to me that it's a big job (especially this late in the game), and that the best we can do is put it on the wishlist for Edition 5.