On Tue 30 Apr 2013 10:23, Kevin Gadd <kevin.gadd at gmail.com> writes:

> Is the reason why you wouldn't want to run finally blocks in generators
> described elsewhere on the list?

I am not sure I understand the question.  Certainly you want run finally
blocks in response to normal control flow in a generator:

  function* g() {
    try {
      yield 1;
      try { yield 2; } catch (e) { yield e; }
      yield 3;
    } finally {
      yield 4;
    }
    yield 5;
  }
  function Sentinel() {}
  function Sentinel2() {}
  var iter;

  iter = g();
  assertEquals(1, iter.next());
  assertEquals(2, iter.next());
  var exn = new Sentinel;
  assertEquals(exn, iter.throw(exn));
  assertEquals(3, iter.next());               // ***
  assertEquals(4, iter.throw(new Sentinel2));
  assertThrows(function() { iter.next(); }, Sentinel2);
  assertThrows(function() { iter.next(); }, Error);

However.  If I understand your question correctly, your question is, if
we just stop after the line marked "***" above, does the "finally {yield
4}" block ever run?

To run finally blocks when a generator object is suspended within the
try{} of a try/finally block is to introduce finalizers into ECMAScript.
So if this is really what you want, then your question is "why is it a
bad idea to add finalizers to ECMAScript".  I think these slides from
Hans Boehm fairly describe the situation:

  http://www.hpl.hp.com/personal/Hans_Boehm/misc_slides/java_finalizers.pdf

Finalizers can be useful but they are not a great interface, they
introduce concurrency, and they are otherwise not currently part of the
language, and so for example V8's great GC hasn't had to deal with
them, which is a win for web performance.  Better to avoid adding them
to the language, especially in this oblique way.

Andy

On Tue 30 Apr 2013 10:23, Kevin Gadd <kevin.gadd at gmail.com> writes:

> Is the reason why you wouldn't want to run `finally` blocks in generators described elsewhere on the list?

I am not sure I understand the question.  Certainly you want run `finally` blocks in response to normal control flow in a generator:

```js
function* g() {
  try {
    yield 1;
    try { yield 2; } catch (e) { yield e; }
    yield 3;
  } finally {
    yield 4;
  }
  yield 5;
}
function Sentinel() {}
function Sentinel2() {}
var iter;

iter = g();
assertEquals(1, iter.next());
assertEquals(2, iter.next());
var exn = new Sentinel;
assertEquals(exn, iter.throw(exn));
assertEquals(3, iter.next());               // ***
assertEquals(4, iter.throw(new Sentinel2));
assertThrows(function() { iter.next(); }, Sentinel2);
assertThrows(function() { iter.next(); }, Error);
```

However.  If I understand your question correctly, your question is, if
we just stop after the line marked "***" above, does the `finally {yield 4}` block ever run?

To run `finally` blocks when a generator object is suspended within the
`try{}` of a `try`/`finally` block is to introduce finalizers into ECMAScript.
So if this is really what you want, then your question is "why is it a
bad idea to add finalizers to ECMAScript".  I think these slides from
Hans Boehm fairly describe the situation:

http://www.hpl.hp.com/personal/Hans_Boehm/misc_slides/java_finalizers.pdf

Finalizers can be useful but they are not a great interface, they
introduce concurrency, and they are otherwise not currently part of the
language, and so for example V8's great GC hasn't had to deal with
them, which is a win for web performance.  Better to avoid adding them
to the language, especially in this oblique way.