Closed
Description
With #758 (hopefully) soon landing to address #256 we will soon have unhandled promise rejections reported to the process via a process.on("unhandledRejection"
event.
One issue that was deliberately deferred from that issue and PR is what the default behaviour of an unhandled promise rejection detected be.
Just to be clear - this is about the default behaviour of a rejected promise with no catch
handler (or then
handler with a function second argument) attached.
The different approaches
- Logging the rejection to the console.
- Throwing an error for
process.on("uncaughtException"
to deal with. - Causing the process to exit.
- Do nothing by default.
There are several good arguments for each approach. I'll write down the arguments I'm aware of and will edit arguments as people make them in comments.
Logging
- No silent failure by default.
- Does not break any existing code - no "surprises". (See comment by @vkurchatkin on this)
- Been a default in several userland libraries like bluebird and users have been very satisfied with it.
Throwing an error
- A promise rejection is the asynchronous version of a thrown exception.
- Does not ignore logical errors or leave the app in an inconsistent state.
- False positives are extremely rare - and code causing them can arguably easily be refactored to not cause them by not attaching error handlers too late.
Process Exit
- Differentiation between uncaught exceptions and promise rejections might be useful.
Do nothing
- Reliable promise rejection detection is non-deciable, it's possible to report an unhandled rejection that actually is handled at a later point if the catch handler is attached at a very late time.
- Does not break any existing workflows for anyone. No backwards compatibility issues for native promise users at all.
- Does not make any assumptions on how people use native promises.
What do people think the default behaviour should be?