[nubs]

The way I handle situations like this is to only put the catches where I need them to serve some purpose. Generally, I don't catch errors at the start of the chain because I can't know what to do with them at that point. If I do catch them, it's only for logging or similar purposes and I still let the error propagate further.

One pattern I use is to rethrow the error:

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

Another pattern I use is to split the promise chain so that I let my main results flow be the result that gets passed on, but I can do other things in a parallel manner internally:

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

[forgotpwtomain]

> 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...

[nubs]

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.

[WorldMaker]

«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

[eyko]

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.