undefined | Better HN

0 pointsforgotpwtomain9y ago0 comments

> return service.fetchData().then((data) => {}).catch((err) => {console.log(err); throw err;});

Yes - but this kind of code requires that you know that something else chains the promise and handles 'err' - which is my entire complaint, a higher level function shouldn't need to know whether it has children or if they do error handling. Otherwise it's back to the same kind of callback style where you have to go into another file and modify a top-level function to accommodate adding a child.

Edit:

I would rather you and the other commentators here re-read my parent post, as well as the relevant resources[0][1][2] - I seriously think I'm repeating the same thing for the 4th time here, no - I don't need an explanation of how promises work; I only was pointing out that the previous (2.0) dferred.promise model actually fits most better in most of use cases that I've experienced than the es6 one and I found that quite curious; but it seems impossible to have that discussion without being on the same page first.

[0] https://blog.jquery.com/2016/06/09/jquery-3-0-final-released...

[1] https://api.jquery.com/deferred.promise/

[2] https://developer.mozilla.org/en/docs/Web/JavaScript/Referen...

0 comments

nubs9y ago

It doesn't need to care whether someone else is handling it. It should just do what it needs to do according to its contract. The caller that receives the promise as a result has its own contract that may or may not involve handling the error as well (and so on up the chain).

You generally have to have an end-of-the-chain catch as a safety precaution. If you don't have one and the promise fails you may get no feedback that an error happened at all. All methods that return promises should be able to expect the caller to handle them appropriately whether they pass or fail - it's not their responsibility to try and figure out how to handle an error in the context of the wider application.

WorldMaker9y ago

«You generally have to have an end-of-the-chain catch as a safety precaution. If you don't have one and the promise fails you may get no feedback that an error happened at all.»

This will be increasingly less of a need as browser native promises catch up (and more reason to make sure that the promise library you are using is built on top of native promises rather than rolled from scratch). Several browser dev consoles will already show unhandled promise rejections today, and there's a growing convergence to also providing browser/system-wide event handlers for unhandled rejections as well.

http://www.2ality.com/2016/04/unhandled-rejections.html

eyko9y ago

You're returning a promise. At that point you've already assumed that something else is going to expect a promise, and a promise can either succeed or fail.

1 more reply

j / k navigate · click thread line to collapse