-
Notifications
You must be signed in to change notification settings - Fork 29.9k
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
Should domains catch unhandledRejection
events
#20474
Comments
cc @nodejs/diagnostics |
I am -1 to do anything to domains. I think we should remove them as soon as async_hooks exits experimental. Ideally we could still maintain a userland implementation of them (they are implemented on top of async_hooks anyway). |
-1. |
I'm -1 on changes to domains at this point. They are a dangerous and problematic API. I think we need them around for a while so that people can migrate to async-hooks or other higher level alternatives. |
I get your points but I still feel we could go further here:
At this point, domains are still used a lot (I know a handful of new projects which rely on them). |
We are almost there, but there is one feature we can't support and we need another semver major release (node.js 11) before we can remove support for that feature. See DEP0097. This feature addition makes sense to me, the only reason why it shouldn't be added is that we wish to remove domains. If we declare make an official effort to move |
Something that hasn't been discussed is the fact that we rely on the |
Closing as this will probably not happen. |
I have been thinking about this for a while and now that domain API relies on Async Hooks, it would probably make sense by symmetry to catch
unhandledRejection
events in domains.but
What is your take on this? I might be missing some previous discussions on that topic, sorry if it's the case 👼 .
cc @nodejs/domains @mmarchini
The text was updated successfully, but these errors were encountered: