On Jul 23, 2014, at 1:25 AM, Andy Wingo wrote:

> Hi,
> 
> The TC39 notes do not record any discussion of return() causing an
> exception to be thrown.

In the latest ES6 draft for-of propagates any exceptions thrown by the call to return(). See http://people.mozilla.org/~jorendorff/es6-draft.html#sec-runtime-semantics-forin-div-ofbodyevaluation step 3.k.ii.1-2  


As a matter of design policy we rarely, if ever, just drop exceptions.


> 
> I understand that one of the concerns was about guards and catch blocks,
> but making return() throw an exception does not affect that in the
> least.
> 
> It's already the case that any catch block may see any old exception.
> Adding a new kind of exception doesn't affect that; properly written
> catch blocks have to test the positive presence of the exception they
> are looking for, not the absence of exceptions they aren't interested
> in.  Magical return() is no better here because, as you note, return can
> be caught too.
> 
> There are valid cases in which you can have a catch without a guard;
> these are when can enumerate the possible exceptions that a part of your
> program will throw.  However this condition necessarily limits the size
> of the try{} block -- it is unlikely to contain a yield.  So no problem
> there either.

It's not exactly clear to me what your point is here.  If you want to catch any exception (including those originating from a return() call to  the iterator) that can occur within while executing a for-of statement you would code:

try {
  for (let each of expr) {...}
} catch (e) {... };

If you only want to catch exceptions from the for-of body you would code:

for (let each of expr) {
   try { ...
  }  catch (e) { ...};
}
   

Allen



-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/es-discuss/attachments/20140723/7baa0499/attachment.html>

On Jul 23, 2014, at 1:25 AM, Andy Wingo wrote:

> The TC39 notes do not record any discussion of return() causing an
> exception to be thrown.

In the latest ES6 draft for-of propagates any exceptions thrown by the call to return(). See http://people.mozilla.org/~jorendorff/es6-draft.html#sec-runtime-semantics-forin-div-ofbodyevaluation step 3.k.ii.1-2  


As a matter of design policy we rarely, if ever, just drop exceptions.


> I understand that one of the concerns was about guards and catch blocks,
> but making return() throw an exception does not affect that in the
> least.
> 
> It's already the case that any catch block may see any old exception.
> Adding a new kind of exception doesn't affect that; properly written
> catch blocks have to test the positive presence of the exception they
> are looking for, not the absence of exceptions they aren't interested
> in.  Magical return() is no better here because, as you note, return can
> be caught too.
> 
> There are valid cases in which you can have a catch without a guard;
> these are when can enumerate the possible exceptions that a part of your
> program will throw.  However this condition necessarily limits the size
> of the try{} block -- it is unlikely to contain a yield.  So no problem
> there either.

It's not exactly clear to me what your point is here.  If you want to catch any exception (including those originating from a return() call to  the iterator) that can occur within while executing a for-of statement you would code:

```js
try {
  for (let each of expr) {...}
} catch (e) {... };
```

If you only want to catch exceptions from the for-of body you would code:

```js
for (let each of expr) {
   try { ...
  }  catch (e) { ...};
}
```