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

Add a flag NODEJS_CATCH_REJECTION to control handling of unhandled rejections in node #9061

Merged
merged 3 commits into from
Jul 26, 2019

Conversation

kripken
Copy link
Member

@kripken kripken commented Jul 22, 2019

Helps #7855, #9028 in that it enables users to disable this.

We can't disable it by default because due to the current node behavior, some errors would not be reported (the node return code would be 0).

…uring async instantiation may behave oddly (they hang for a few seconds, node warns this behavior will be fixed in the future, and it exits with a 0 returncode), which is a downside, but the upside is that it avoids confusion for developers that get the handler popping up when they didn't expect it. Alter a test to work around this. Fixes #7855, #9028.
…errors during async instantiation may behave oddly (they hang for a few seconds, node warns this behavior will be fixed in the future, and it exits with a 0 returncode), which is a downside, but the upside is that it avoids confusion for developers that get the handler popping up when they didn't expect it. Alter a test to work around this. Fixes #7855, #9028."

This reverts commit f132637.
… of unhandled rejections in node. This is useful if a dev doesn't want it to interfere with their own code. We don't set this to 0 by default because it would mean some wasm errors end up not returning a non-zero return code from node (still true as of 12.4.0)
@kripken kripken requested a review from tlively July 25, 2019 19:57
Copy link
Member

@tlively tlively left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

LGTM

@donmccurdy
Copy link

@kripken Under what conditions could a library built with Emscripten safely disable this option? For example:

  • Enable during local development, disable in production.
  • Disable if the library handles all expected errors itself, enable otherwise.
  • ... something else?

A library I'm using has kept the default settings, and it's causing issues in my application (which has its own error handlers). I'd like to ask the library to change the setting, but we're not sure what the implications of that would be.

@kripken
Copy link
Member Author

kripken commented Oct 14, 2020

It should be safe to disable this if you are not worried about the return code from the program. The problem this solves is that node "ignores" a failure, and the return code is 0. That matters a lot in a test suite, but maybe not in production?

Note that #12408 may fix this more properly soon.

belraquib pushed a commit to belraquib/emscripten that referenced this pull request Dec 23, 2020
…jections in node (emscripten-core#9061)

* Add NODEJS_CATCH_REJECTION, a flag that allows disabling the catching of unhandled rejections in node. This is useful if a dev doesn't want it to interfere with their own code. We don't set this to 0 by default because it would mean some wasm errors end up not returning a non-zero return code from node (still true as of 12.4.0)

Helps emscripten-core#7855, emscripten-core#9028
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

Successfully merging this pull request may close these issues.

None yet

3 participants