What to do with unhandled broken promises?

[smarr]

Currently, unhandled broken promises can lead to errors being swallowed.

However, we can't really add a standard behavior, because having that overwritten by a handler that's set later would be observably racy.

Node.js uses at the moment a warning that is displayed for such promises.
However, they seem to switch to a more radical approach and seem to want to shut down the whole application when such a broken promise is not handled.

That's derived from the follow example error message:

(node:2622) UnhandledPromiseRejectionWarning: Unhandled promise rejection (rejection id: 1): Error: SOMns failed to starting WebSocket and/or HTTP Server

We could go a similar route, however, I am not sure that just killing the whole process is a good and robust approach.

[smarr]

There is also the problem of having an observable race condition.
We got a race between:

• a promise becoming broken (resolved with error)
• registering an error handler on the promise

This is observable if we give a warning when the promise is broken.
One possible solution might be to defer resolution to turn boundaries.
Currently, promises are resolved directly, using locking.
If we make them part of the message sending queue, or possibly another queue, we may avoid that.

It might be worth trying it and measuring what the overhead is.