Generator issue: exceptions while initializing arguments

Allen Wirfs-Brock allen at
Sat Sep 8 13:01:03 PDT 2012

This is the first of probably several semantic issues WRT generator that will need to be resolved in the spec.

Here is the user level issue:

let thrower = {throw () {throw "exception"}};
function * G(arg = thrower.throw()) {
   //possibly other explicit initialization code which could also throw
   yield arg;
let g = G();   //do we see "exception" here?  (loc 1)
... //possibly many lines of code;       //or do we see it here (loc 2)

The generator proposal [1] doesn't really address this issue.  It assumes [2] that an environment record with the parameter bindings can be created and captured at loc 1 without triggering any exceptions and it defers instantiation and execution of all of the generator's code body until the first "next" call.  However, the semantics of parameter default value initialization can result in exceptions and more closely links argument instantiations with the actual activation of the generator function. You can't really build the parameter bindings without performing declaration instantiation for the function.

Arguably, exceptions involving initialization of the the parameter would be more meaningful at loc 1  (loc 2 could be very remote and in somebody else's code). However, the body of the generator may contain other explicit initialization code and there really is no way to identify and move evaluation of that code (and its possible exceptions) to loc 1. So, even if parameter initialization exceptions are made observable at loc 1 there may still be other logical initialization-related exceptions that will onlybe  observable at loc 2. 

Which semantics do we want?  Deferring parameter initialization to loc 2 may be somewhat simpler from a specification perspective.  It's hard to say which would have bigger implementation impact.



-------------- next part --------------
An HTML attachment was scrubbed...
URL: <>

More information about the es-discuss mailing list