search

RubenVerborgh / AsyncIterator

An asynchronous iterator library for advanced object pipelines in JavaScript
https://rubenverborgh.github.io/AsyncIterator/docs/
Other
48 stars 7 forks source link

What happens to iterators after they error? #92

Open RubenVerborgh opened 2 years ago

RubenVerborgh commented 2 years ago

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

jeswr commented 2 years ago

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 2 years ago
  • 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 2 years ago

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 2 years ago

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