Stream behavior with errors
See original GitHub issueIf the call to the download
function below fails with an error, stopOnError
will cause the Promise
to reject
. Since this is doing parallel(10)
, will this code wait for the other 9 download
operations to finish, or will it terminate them right away when it encounters the first error?
How will the behavior be different if I use mergeWithLimit(10)
instead of parallel(10)
?
await new Promise((res, rej) => highland(range)
.map(page => highland(download(page)))
.parallel(10)
.stopOnError(rej)
.done(res));
Issue Analytics
- State:
- Created 7 years ago
- Comments:5
Top Results From Across the Web
How do I throw an error on a behaviour subject and continue ...
Retrieval/creation of the data: A stream, that will run once then then completes and/or throws an error whenever one occurs. When the data...
Read more >Error Streams Sample
Error ports and error streams allow application authors to handle errors as data. You can apply local logic to error processing using StreamBase...
Read more >Node.js Streams Inherit Error-Handling Behavior From ...
Ben Nadel demonstrates that the error handling behavior in Node.js streams is inherited from the EventEmitter module.
Read more >Controlling Error Reporting Behavior and Intercepting Errors
If you don't use either of those, the error is written to the Error stream, and the current script block continues with the...
Read more >Analysis of Behavioral Streams 1 Running head
observed streams of behavior; such scores then serve subsequent analyses. ... It places some burden on observers, however, and can be error prone...
Read more >Top Related Medium Post
No results found
Top Related StackOverflow Question
No results found
Troubleshoot Live Code
Lightrun enables developers to add logs, metrics and snapshots to live code - no restarts or redeploys required.
Start FreeTop Related Reddit Thread
No results found
Top Related Hackernoon Post
No results found
Top Related Tweet
No results found
Top Related Dev.to Post
No results found
Top Related Hashnode Post
No results found
Top GitHub Comments
Yes.
You can call
rej
insideerrors
instead of pushing the error along. Like thisIt’s important to call
rej(err)
first, before pushnil
. Pushingnil
first may cause the stream to end anddone(res)
to execute before you get a chance to reject the promise, causing you to end up with a resolved promise instead of a rejected one. This is a quirk of the current implementation.That said, I personally think it’s too easy to accidentally transpose the two lines, and it’s not immediately obvious that order matters, so I wouldn’t recommend doing this. Your solution using
stopOnError(rej)
is less error-prone.It’s perfectly fine to not push anything. That’s one of the primary uses of
errors
—to handle certain errors and filter them out from the stream.parallel
will hold back errors the same way that it holds back stream values due to its ordering guarantee.mergeWithLimit
will emit the error as soon as it gets it.stopOnError
will stop the stream from consuming new data (and thus stop new operations from being started), but it does not cancel download operations that have already started.Let’s say you have 15 download operations to process, your parallelism factor is 10, and the 3rd download fails.
With
parallel
parallel
will emit the error in order, so when your promise is rejected,With
mergeWithLimit
mergeWithLimit
will emit the error as soon as possible, so when your promise is rejected,Using
merge
doesn’t tell you much about the download operations on errors. That’s the price you pay for the better memory usage and more parallelism. That said, if you want to know which downloads completed before the error, you can resolve the Promise thatdownload
returns with some id (say the page number) when the download completes. These values will be emitted before the error if the download completed before the error.Note that you do not have to use
stopOnError
. There is also errors. It’s just there as an example, because you want to handle errors somehow (done
will throw if it encounters an unhandled error). But it’s up to you how you want to handle them.