Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

2 problems with Reject throwing errors #39

Open
cscalfani opened this issue Feb 8, 2013 · 2 comments
Open

2 problems with Reject throwing errors #39

cscalfani opened this issue Feb 8, 2013 · 2 comments

Comments

@cscalfani
Copy link

  1. Unhandled errors in reject throw errors in a setTimeout making catching them impossible. It would be nice to NOT use setTimeout if exports.errorTimeout == 0.
  2. When the error is thrown, it should be wrapped in an Error() if not already instanceof Error so a stack trace can be had.

Currently, there is no way to catch a forgotten call to reject with a dontThrow parameter. The exception is caught in an unhandled exception handler but that kills my app (as it should).

Also, it would be nice if this behavior was documented.

@cscalfani
Copy link
Author

After looking at a failed attempt to override the reject() function in my code since I don't have access to "handled" variable, I realize that the best solution for this would be to simply wrap the error in Error().

But this should be done OUTSIDE of the setTimeout function so we can capture the stack frame of the reject call that's not handled.

@cscalfani
Copy link
Author

Sorry for so many comments, but I just realized that if you wrap the error in UnhandledRejectError then I can have a unhandled exception handler NOT exit the app when this type of Error is thrown. If you simply wrap it in an Error() then I cannot "know" that it's a recoverable unhandled exception.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant