-
Notifications
You must be signed in to change notification settings - Fork 29.7k
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
Add a new process.unhandledRejections
runtime flag
#33577
Comments
Would setting the flag via NODE_OPTIONS help the "complex systems" use case? Or maybe setting the unhandledRejection handler? If we implement this, it shouldn't be possible to override |
I don't understand why this needs another programmatic interface and setting a |
The problem with setting an
Because Node's default error handling behavior is unexpected, even arguably broken. Should we really have to set an
When Until then, I want to be able to add a single line of code to my scripts/applications, and know that it's going to work correctly as long as I have a recent version of Node. "Correctly" in this case means that unhandled errors should abort the process with a clean, clear stack trace.
Not really, because (1) this can't be set from within application code, and (2) even if it could, doing so would override anything else that had previously set |
@nylen thanks for sharing more context. I'm not objectively against it as I understand different environments and infrastructures have different constraints, but as I mentioned above, if we do implement it I'd like to ensure that the flag cannot be overriden (it might even make more sense to leave I think if we can better understand your constraints, it'll be easier to come up with solutions to this problem and to move any changes forward. Is there anything else you can share about the infrastructure you're dealing with (is it serverless, containers, regular cloud instances, mainframes, local machines running Electron, are you starting child processes or clusters, etc.).
It can be achieved with a single line of code (
We are currently discussing the default behavior for unhandled rejections and the default might become (or not) throwing on unhandled rejections, so I'd wait until that decision is reached before moving forward with this.
Regarding (2): environment variables can be extended (well, concatenated, (1) makes me even more curious about your use case: it sounds like this is targeted at environments where you don't have control on how the Node.js process is launched (so likely a serverless infrastructure)? Please correct me if my assumption is wrong. |
FWIW this is one of my biggest regrets and failures in Node and this is being fixed. @mmarchini wrote a survey nodejs/TSC#857 that is being sent to users now. Given the results the project TSC will make a decision and possibly land #33021 or a similar PR (hopefully). You can work around the issue by setting FWIW:
process.on('unhandledRejection', e => { throw e; }); Should meet those constraints IIUC. |
Glad to hear it. I think we (programmers in general) learned a long time ago that unhandled errors should abort, any other behavior is asking for trouble in complex systems.
As I explained above, application code needs to be able to control this behavior.
I have dozens of Node.js projects running in different environments, being launched different ways. Cron jobs (system and cPanel), init scripts, things launched in bash running in tmux sessions, with So, in theory I have full control over all of this code and how it's launched, but in practice I don't, because I can't realistically look back through every place where a Node.js process is launched (including child processes) and confirm that it has the right command-line options. Then, if I were to move my code to such a serverless environment as you suggested, it would suddenly break, unless the application code itself has full control over error handling behavior. Many people are likely in similar situations, which is why I created this issue to further push towards a simple solution and further push towards "ideal" error handling behavior.
I agree something like this is probably still the best solution today. However, this is still 3 lines of code under most formatting rulesets, and setting a runtime flag as suggested in this issue would still be an improvement, because I wouldn't have to test and understand as many subtleties of Node.js error handling in order to use it. Tools that don't make programmers think about such issues are a good thing.
Thanks for the links. That would be a full fix which would eliminate the need for this issue as far as I'm concerned. I'll be following this with interest. |
Sounds fine, but I probably wouldn't leave Maybe the runtime behavior should be whichever of |
This seems very dangerous to me. I don't want to have to protect my node application against any arbitrary third-party code being able to change the unhandled rejections mode of my entire application, at any time. |
@ljharb's point of this giving third-party access to changing is very concerning to me too. I feel like working around this on user land would turn out being more complex than the event handler itself. |
To be fair, that's entirely possible today (and with sync exceptions) through the I think this problem is not solved well currently (boundaries) and adding this hook doesn't change that. I am still not sure what's the issue with |
Is your feature request related to a problem? Please describe.
Unwieldy or incorrect behavior related to stack traces from unhandled promise rejections, depending on command-line options used.
Follow-up to #32312 (comment) and #17871.
Describe the solution you'd like
Add a new runtime flag:
process.unhandledRejections = 'strict';
This should behave the same way as setting
--unhandled-rejections=strict
when launching Node.js.Relevant documentation for already existing feature: https://nodejs.org/api/cli.html#cli_unhandled_rejections_mode
This new flag should also be documented near here: https://nodejs.org/api/process.html#process_process_throwdeprecation
After landing #32312, this situation has gotten better. However the stack trace from such an error is still overly long and unwieldy (lots of extraneous information):
Stack trace with `process.throwDeprecation = true;` after #32312
With
--unhandled-rejections=strict
the output is somewhat cleaner:Stack trace with `--unhandled-rejections=strict`
Why a further change is needed
Currently there is not an easy and foolproof way to get guaranteed error exits from unhandled rejections, with clean stack traces. The best current solution is to change how all Node.js processes are launched and add
--unhandled-rejections=strict
to their command line. In a complex system, there are multiple ways that Node.js processes can be launched, so this is difficult to achieve fully.This solution of adding a new runtime flag should allow us to just add a single line to our code instead, which should guarantee the desired behavior for all scripts that contain this line.
The text was updated successfully, but these errors were encountered: