[md224]

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

[forgotpwtomain]

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

Well if it's not handled there is simply no further promise-chain to call. If you maintain a large-enough app, you probably have some kind of tool for reporting client-side javascript errors. When you have unhandled promises it's not always clear that they are unhandled because you handled it and just happened to re-throw even though the promise has no further chain, or whether someone messed up and actually isn't handling a rejection. Thus to avoid this, adding new promise to a chain involves finding the first .catch(), adding a throw, and an extra .catch() further down the chain.