To stop on, or collect errors?

[Quentin Engles]

I'm wondering what everyone's opinion is on handling errors over time.

In the interfaces of some modules I've seen errors collected into an array with an errors parameter in the callback. Used this way all jobs are done even after an error is encountered.

In others when an error is encountered the remaining jobs are quit, and a single error parameter is used in the callback.

On error at least one job is incomplete either way, but with the error collector style future jobs are still complete.

There is array, or single aggregated error style for the parameter. So this question really isn't about array of errors vs. single error. What I'd like to know is should future jobs after error be complete, or should errors stop all jobs?

There is also on('error', cb), but that is just another optional implementation detail. I want to stick with non-event style interfaces in this conversation.

[Daniel Rinehart]

It really depends on context. Do the semantics of the API indicate that trying to do as much work in parallel with a few errors is okay (errors parameter) or it is an all or nothing approach (single error parameter). In some cases you might want to leave that decision up to the caller and provide both options, something akin to the difference between Promise.all and Promise.race.

-- Daniel R. <dan...@neophi.com> [http://danielr.neophi.com/]

--
Job board: http://jobs.nodejs.org/
New group rules: https://gist.github.com/othiym23/9886289#file-moderation-policy-md
Old group rules: https://github.com/joyent/node/wiki/Mailing-List-Posting-Guidelines
---
You received this message because you are subscribed to the Google Groups "nodejs" group.
To unsubscribe from this group and stop receiving emails from it, send an email to nodejs+un...@googlegroups.com.
To post to this group, send email to nod...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/nodejs/8c39cf77-f502-472a-b3e7-b6634dfe9f74%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Quentin Engles]

The situation I'm talking about is a lot of related jobs happening at once like reads, and writes. The problem is when it isn't all, or nothing. Sometimes it's all, or some. When there are jobs like multiple asynchronous writes happening some will finish even though there may be an error by one, or two of those writes.

I know there's options, but I'm asking about opinion, or best practice.

The Promise interface is a good example, but I'd like to see more.

There are also ways to force all, or nothing by having functions that undo a queue of work on error, but I'd like to see what can be said about the specifics of all, or some.

[Daniel Rinehart]

I'm not familiar with that many APIs that support partial failure. A couple that come to mind that I've used and may provide some ideas:

https://developers.google.com/adwords/api/docs/guides/partial-failure
http://facebook.github.io/graphql/#sec-Errors

-- Daniel R. <dan...@neophi.com> [http://danielr.neophi.com/]

To view this discussion on the web visit https://groups.google.com/d/msgid/nodejs/301a5356-e604-4d5f-9d36-7e9ac36e4b1c%40googlegroups.com.

[Quentin Engles]

There are many times of partial successes though. Some artifacts of work will still remain even if there was full stop failure.

Some bulk file operators are like this. HTTP servers are like that during uptime for pages served, though we wouldn't want a collection of HTTP errors from a server except in a log.

I am beginning to think if it's a publicly available module it should be a choice for the consumer. That adds complexity to a module though.