You should only ever be squashing an error into a success response if that's what someone would be expecting but that's rarely the case. Normally you should be allowing the error to bubble up and be decided by the caller.

I can think of a couple cases where catching an error down low with the purpose of squashing it makes sense. One would be for a service that you know may not have data and you don't care if it doesn't. For instance, trying to get geolocation data for a user in order to improve their experience but if it fails you don't need to show an error:

return geolocationService.fetch().catch((err) { /* log error /; return {}; / empty result/ });

Another case is when you might have multiple ways of handling the request where one is prioritized over the other. In this case, you can catch errors from the first attempt and try a second method. If they both error out, then the result promise will be an error as well.

return primary.fetch().catch((err) => { return secondary.fetch(); }).then((data) => { / manipulate data */});

> Therefore whether you re-throw the error or squash it depends on whether another 'reject' function will be there to squash it further down the chain etc.

Does it matter if another 'reject' function is there to squash it? I was under the impression that unhandled rejections would just vanish into the ether... no need to worry about another promise handling them. Just re-throw the error and forget about it.

Edit: To be clear, the browser may display an error in the console as a diagnostic tool, but my impression is that unhandled rejections will not result in an actual exception that halts execution.

Edit 2: Here's a fun example for the Chrome console:

    var p = Promise.reject();
    setTimeout(() => p.catch(e => {}), 1000);

It displays an error... and then a second later the error transforms into a non-error!