Unhandled promise rejections are confusing to new users
I try to monitor and answer Node.js promise questions in StackOverflow. Several times now this sort of question arises where the OP gets an unhandled rejection error:
(node:52553) UnhandledPromiseRejectionWarning: Unhandled promise | rejection (rejection id: 1): ReferenceError: user is not defined | (node:52553) [DEP0018] DeprecationWarning: Unhandled promise > rejections are deprecated. In the future, promise rejections that are > not handled will terminate the Node.js process with a non-zero exit > code.
Which I then explain is just a regular error wrapped in an UnhandledPromiseRejectionWarning
.
I think changing the error format could really help the user understand the problem. Currently the average async/await user has to:
- Understand unhandled rejections and promise semantics to a reasonable degree.
- Understand that it's probably just an unhandled exception in promise land.
- Understand they need to run with
--trace-warnings
in order to get a reasonable stack trace for said error.
I think the current error format is pretty unwelcoming to new users and while it is a huge improvement over swallowing the error by default or not having a hook into it - we should improve it.
This issue is about the phrasing of the current warning and does not interfere with ongoing efforts to throw on unhandled rejections when they're detected in GC.
Does anyone have any better naming suggestions?
(Note, I'd prefer (if possible) that we keep using the existing warnings infrastructure for the warning)