On Jul 23, 2014, at 11:21 AM, Jeremy Martin wrote:

> Now that we have return() it isn't clear to me that we actually need throw()
> 
> Am I understanding correctly that you're suggesting removing throw from Generator.prototype?
> 
> If so, I'd like to suggest that, at a minimum, .throw() has been rather useful in the context of Node.js control-flow libraries [1] that surface "catchable" asynchronous errors.
> 
> [1] https://github.com/jmar777/suspend#error-handling
> 

I see, your example is using generators like the first perspective I described in my response to Brendan.  The generator is essentially in control and sees the 'yield' as a call to an operation for which it is prepared to handle exceptions. It's logically splicing together two call chains. Essentially using a generator as a co-routine.

Ok, I buy that throw() is useful for that use case.  I still think it is a different from the looping control structure case where the loop is in control rather than the iterator.

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

On Jul 23, 2014, at 11:21 AM, Jeremy Martin wrote:

> Am I understanding correctly that you're suggesting removing throw from Generator.prototype?
> 
> If so, I'd like to suggest that, at a minimum, .throw() has been rather useful in the context of Node.js control-flow libraries [1] that surface "catchable" asynchronous errors.

I see, your example is using generators like the first perspective I described in my response to Brendan.  The generator is essentially in control and sees the 'yield' as a call to an operation for which it is prepared to handle exceptions. It's logically splicing together two call chains. Essentially using a generator as a co-routine.

Ok, I buy that throw() is useful for that use case.  I still think it is a different from the looping control structure case where the loop is in control rather than the iterator.