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. On Friday, July 17, 2015 at 12:46:34 PM UTC-5, Daniel R. wrote: > > 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. <[email protected] <javascript:>> [http://danielr.neophi.com/ > ] > > On Fri, Jul 17, 2015 at 8:13 AM, Quentin Engles <[email protected] > <javascript:>> wrote: > >> 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. >> >> On Thursday, July 16, 2015 at 1:30:27 PM UTC-5, Daniel R. wrote: >>> >>> 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. <[email protected]> [http://danielr.neophi.com/] >>> >>> On Wed, Jul 15, 2015 at 8:20 PM, Quentin Engles <[email protected]> >>> wrote: >>> >>>> 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. >>>> >>>> -- >>>> 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 [email protected]. >>>> To post to this group, send email to [email protected]. >>>> To view this discussion on the web visit >>>> https://groups.google.com/d/msgid/nodejs/8c39cf77-f502-472a-b3e7-b6634dfe9f74%40googlegroups.com >>>> >>>> <https://groups.google.com/d/msgid/nodejs/8c39cf77-f502-472a-b3e7-b6634dfe9f74%40googlegroups.com?utm_medium=email&utm_source=footer> >>>> . >>>> For more options, visit https://groups.google.com/d/optout. >>>> >>> >>> -- >> 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 [email protected] <javascript:>. >> To post to this group, send email to [email protected] >> <javascript:>. >> To view this discussion on the web visit >> https://groups.google.com/d/msgid/nodejs/301a5356-e604-4d5f-9d36-7e9ac36e4b1c%40googlegroups.com >> >> <https://groups.google.com/d/msgid/nodejs/301a5356-e604-4d5f-9d36-7e9ac36e4b1c%40googlegroups.com?utm_medium=email&utm_source=footer> >> . >> >> For more options, visit https://groups.google.com/d/optout. >> > > -- 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 [email protected]. To post to this group, send email to [email protected]. To view this discussion on the web visit https://groups.google.com/d/msgid/nodejs/9976b0b7-766d-4ecc-9453-a3da0c94d932%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
