-
Notifications
You must be signed in to change notification settings - Fork 29.6k
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
vm: never abort on caught syntax error #17394
Conversation
constructor(code, options) { | ||
// Calling `ReThrow()` on a native TryCatch does not generate a new | ||
// abort-on-uncaught-exception check. A dummy try/catch in JS land | ||
// protects against that. |
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.
@nodejs/v8 Is this a bug in V8?
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.
Yeah a ReThrow is not actually a new throw. It just "re-activates" the exception.
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.
@hashseed Does that mean one could get the right behavior by exiting the TryCatch
scope, then using isolate->ThrowException()
?
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.
Yeah. Though the message you get with this kind of "rethrow" will show the stack trace of the new throw location.
4e7ba98
to
250ab47
Compare
Hm – looks like message tests fail, because the throw in JS makes us drop the filename from the output… going to need to look into this a bit more I guess |
250ab47
to
62233c9
Compare
Okay, I think I fixed it with some … cleverness. I’d appreciate it if @bnoordhuis could take a look? |
try { | ||
super(code, options); | ||
} catch (e) { | ||
throw e; /* node-do-not-add-exception-line */ |
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.
Any idea for how to avoid this? Or: Is this even actually a bad thing?
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.
Why would it be a bad thing?
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.
I am not sure - it seems like something that people might find out, start to use, and be unhappy when they find out we changed/removed/etc. it
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.
I'm not sure what "it" refers to. The line in the (decorated) stack trace? What info could they glean from that?
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.
No, sorry, I should have been clearer - I was talking about the node-do-not-add-exception-line
magic string and its effect of not appending the filename + arrow string in that case
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.
Hah, okay. I read your question as "is it a bad thing for the throw to show up." I wouldn't say so, and yes, I'd say it's only a matter of time before people find out about the magic comment. :-)
If you want to exclude stack frames, you can filter based on the script id. Probably overkill for this, though.
This is unnecessary since we only run `AppendExceptionLine()` once per exception at this point anyway.
Keep track of C++ `TryCatch` state to avoid aborting when an exception is thrown inside one, and re-throw in JS to make sure the exception is being picked up a second time by a second uncaught exception handler, if necessary. Add a bit of a hack to `AppendExceptionLine` to avoid overriding the line responsible for re-throwing the exception. Fixes: nodejs#13258
This is unnecessary since we only run `AppendExceptionLine()` once per exception at this point anyway. PR-URL: #17394 Reviewed-By: James M Snell <jasnell@gmail.com>
Keep track of C++ `TryCatch` state to avoid aborting when an exception is thrown inside one, and re-throw in JS to make sure the exception is being picked up a second time by a second uncaught exception handler, if necessary. Add a bit of a hack to `AppendExceptionLine` to avoid overriding the line responsible for re-throwing the exception. PR-URL: #17394 Fixes: #13258 Reviewed-By: James M Snell <jasnell@gmail.com>
Currently the following warning is show when building: ../src/node_contextify.cc:642:10: warning: unused variable 'display_errors' [-Wunused-variable] bool display_errors = maybe_display_errors.ToChecked(); This commit removes the unused variable which became unused in commit aeddc36 ("src: remove tracking for exception arrow data"). Refs: nodejs#17394
Currently the following warning is show when building: ../src/node_contextify.cc:642:10: warning: unused variable 'display_errors' [-Wunused-variable] bool display_errors = maybe_display_errors.ToChecked(); This commit removes the unused variable which became unused in commit aeddc36 ("src: remove tracking for exception arrow data"). PR-URL: #17491 Refs: #17394 Reviewed-By: Franziska Hinkelmann <franziska.hinkelmann@gmail.com> Reviewed-By: Colin Ihrig <cjihrig@gmail.com> Reviewed-By: Anna Henningsen <anna@addaleax.net>
Should this be backported to |
Currently the following warning is show when building: ../src/node_contextify.cc:642:10: warning: unused variable 'display_errors' [-Wunused-variable] bool display_errors = maybe_display_errors.ToChecked(); This commit removes the unused variable which became unused in commit aeddc36 ("src: remove tracking for exception arrow data"). PR-URL: #17491 Refs: #17394 Reviewed-By: Franziska Hinkelmann <franziska.hinkelmann@gmail.com> Reviewed-By: Colin Ihrig <cjihrig@gmail.com> Reviewed-By: Anna Henningsen <anna@addaleax.net>
Got it to land !!! |
This is unnecessary since we only run `AppendExceptionLine()` once per exception at this point anyway. PR-URL: #17394 Reviewed-By: James M Snell <jasnell@gmail.com>
Keep track of C++ `TryCatch` state to avoid aborting when an exception is thrown inside one, and re-throw in JS to make sure the exception is being picked up a second time by a second uncaught exception handler, if necessary. Add a bit of a hack to `AppendExceptionLine` to avoid overriding the line responsible for re-throwing the exception. PR-URL: #17394 Fixes: #13258 Reviewed-By: James M Snell <jasnell@gmail.com>
Currently the following warning is show when building: ../src/node_contextify.cc:642:10: warning: unused variable 'display_errors' [-Wunused-variable] bool display_errors = maybe_display_errors.ToChecked(); This commit removes the unused variable which became unused in commit aeddc36 ("src: remove tracking for exception arrow data"). PR-URL: #17491 Refs: #17394 Reviewed-By: Franziska Hinkelmann <franziska.hinkelmann@gmail.com> Reviewed-By: Colin Ihrig <cjihrig@gmail.com> Reviewed-By: Anna Henningsen <anna@addaleax.net>
does this make sense for lts? edit: if backported it should come with #17491 |
ping re: backport |
one more backport ping should come with #17491 |
Fixes: #13258
Checklist
make -j4 test
(UNIX), orvcbuild test
(Windows) passesAffected core subsystem(s)
vm