RubenVerborgh/AsyncIterator

What happens to iterators after they error?

Opened this issue · 4 comments

RubenVerborgh commented

Should they be closed? Destroyed? Should there be a special stated for iterators that errored?
Or is recovery possible?

jeswr commented

My proposal is that

  1. Iterators from this library only error during a .read() call (or whilst in flowing mode when a data listener is attached).
  2. If there is at least one error listener - the error is forwarded. Otherwise an error is thrown.
  3. Following the error event the iterator is destroyed.
RubenVerborgh commented
  • Iterators from this library only error during a .read() call (or whilst in flowing mode when a data listener is attached).

I don't think we can enforce that; errors can happen at any random moment.
So when not in flowing mode, the iterator might be preparing something that results in an error.
And there is no guarantee (!) that the read method will be called, so the error would be lost.
Plus we need to be able to accept Node.js Readable, which are allowed to random error.

  • If there is at least one error listener - the error is forwarded. Otherwise an error is thrown.

Check.

  • Following the error event the iterator is destroyed.

Note that proper destruction might not be possible anymore after error, but yes, best-effort destruction seems appropriate. I wonder if there are scenarios where we would not want this though; @rubensworks?

rubensworks commented

Following the error event the iterator is destroyed.

Note that proper destruction might not be possible anymore after error, but yes, best-effort destruction seems appropriate. I wonder if there are scenarios where we would not want this though; @rubensworks?

Yes, I think destroying after error makes sense (at least as default). Can't think of any cases atm where you wouldn't want this.

jeswr commented

I don't think we can enforce that; errors can happen at any random moment. So when not in flowing mode, the iterator might be preparing something that results in an error.

Rather than immediately forwarding an error we can store a pendingError and to set the iterator to readable at that time; the next read() call would then cause the emission of the pendingError.

And there is no guarantee (!) that the read method will be called, so the error would be lost.

Hmm good point