And in browsers Domenic worked on something similar which was added later (because browsers) but will hopefully be standard in all browsers soon (Chrome, since 49):
You mention that - but it's worth pointing out upfront it's a solved problem.
Also:
> The problem is that once again, Promises will swallow subsequent resolutions and more concerningly, rejections. There might be errors that are never logged!
This is arguably a much better design than the alternative - which is to violate the "callback" contract.
I'm glad `unhandledRejection` exists (and I thank you for your work).
Unlike Chrome, without setting up the handler manually, you still don't find out about unhandled rejections. Maybe it's something we could enable during development (`NODE_ENV` = 'development' perhaps).
I've never quite understood why unhandled rejection is a problem by itself. It can only arise if there is a promise that has rejected but has nothing waiting on it. But that means there was nothing waiting for it to resolve successfully either, which is the real bug in the application.
I specced and Node added the `unhandledRejection` hook over a year ago:
process.on("unhandledRejection", (err) => { // handle });
And in browsers Domenic worked on something similar which was added later (because browsers) but will hopefully be standard in all browsers soon (Chrome, since 49):
window.addEventListener("unhandledrejection", (err) => {
});
If you use bluebird - you get that up to IE7.
You mention that - but it's worth pointing out upfront it's a solved problem.
Also:
> The problem is that once again, Promises will swallow subsequent resolutions and more concerningly, rejections. There might be errors that are never logged!
This is arguably a much better design than the alternative - which is to violate the "callback" contract.