-
Notifications
You must be signed in to change notification settings - Fork 583
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
fix: handle unexpected errors #2368
Conversation
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Great change
713d244
to
738efe5
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Self-review based on in-person discussions.
* This function can only be used once in the same process. If you have multiple | ||
* callables needing this, compose them into a single callable. | ||
*/ | ||
export async function callHandlingUnexpectedErrors( |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@maxjeffos how about "safelyCall". Seems like a more minimal solution (vs. inventing an understandable DSL). Might be too generic...
Ensure unexpected errors are handled with Exit Code 2 rather than the NodeJS default 1. We use 1 for vulns found. Node 16 now uses Exit Code 1 for unhandledRejections (rather than only logging), so this also makes us consistent across different Node versions.
Need to wrap index logic in an error handler but doing so will lose file history. This commit will be followed by a new index.js
738efe5
to
a8835ab
Compare
This PR modifies files linked to issues tracked in Stepsize. You might want to review their status, priority, and scope.
|
Ensure unexpected errors are handled with Exit Code 2 rather than the NodeJS default 1. We use 1 for vulns found.
Node 16 now uses Exit Code 1 for unhandledRejections (rather than only logging), so this also makes us consistent across different Node versions.
https://nodejs.org/en/blog/release/v15.0.0/#throw-on-unhandled-rejections-33021
Note for Reviewers
When reviewing, it's best to review through each commit.
I've moved a file and placed a new file in its old place. To avoid losing history, these two steps are in separate commits.
If I didn't do this, git will squash the two changes to look like I deleted a bunch of code and created a new file with a bunch of new code. Obviously, that's not correct. This is what GitHub's PR interface also shows, but it's not how it looks in history with separate commits.
Notes