search

promises-aplus / unhandled-rejections-spec

Discussion and drafts of possible ways to deal with unhandled rejections, across implementations
6 stars 0 forks source link

Track and allow printing of unhandled rejections #6

Open domenic opened 11 years ago

domenic commented 11 years ago

The idea here would be, whenever an unhandled rejection occurs, add it to some array (or perhaps WeakMap). If it gets handled later, remove it from that array.

Then, allow printing of the unhandled rejection list. Either add is as a property to the library, or to a global environment (cf #2), or print it automatically on program exit/window onload, or print it periodically and automatically in debug mode, or...

This seems unlikely to solve the problem by itself. It's not a great experience to debug for hours before thinking to check the magic unhandled rejection list. Tooling could help, but then we're back at #2.

MicahZoltu commented 9 years ago

:+1: I know I am over 2 years late to the party, but I figured I would offer my 2 cents.

The problem I see with any proposal that has immediate consequences for unhandled rejection is that it discourages the use of promises as first class objects. This proposal makes it so you can pass around rejected promises without being slammed with errors by your tools or crashing your app, At the same time, your tools can give you insight into the state of your unhandled rejections at an appropriate time. For example, when you break in a debugger it could immediately show you all unhandled rejections.