-
Notifications
You must be signed in to change notification settings - Fork 459
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
Question about how Error::New() handles last error and exceptions #1089
Comments
Whenever I see a What happens if you swap the order of the |
Hmm, I think in this instance we know that When I swap the It also looks like even though the error code gets overwritten, the error message persists because |
This section describes the planned error handling: https://nodejs.org/api/n-api.html#n_api_return_values The TLDR; is that the doc covers
Separately, we might also want to look at napi_get_last_error_info, and see if we should reset the napi_extened_error_info returned. We could quite likely defer that until napi_get_last_error_info is called (ie clear if the last error is now napi_ok) which would mean we would not add overhead unless napi_get_last_error_info is called when the error has been reset. |
Hey @mhdawson , yeah I think adding that to the doc could help. Though the issue with the |
Yes, I see that the code code does not expect that the data pointed to by info be changed by later calls. We re-use the same structure to avoid allocating/de-allocating but does result in this issue. As you suggest the method should pull the fields it uses out of info earlier to avoid that. |
Fix up example and make it more explicit on how you need to use napi_extended_error_info in order to help people avoid what might be a common mistake that we made in node-addon-api. Refs: nodejs/node-addon-api#1089 Signed-off-by: Michael Dawson <mdawson@devrus.com>
I created this PR to address the doc side: nodejs/node#40458 @JckXia do you want to submit a PR to clear info in napi_get_last_error_info() if the last status was napi_ok? |
We must create a copy of the last error info before using it if subsequent Node-API function calls are involved as those may mutate the fields of the original structure. Fixes: nodejs#1089 Signed-off-by: Darshan Sen <darshan.sen@postman.com>
All fields of the `napi_extended_error_info` structure, except `error_message`, gets reset in subsequent Node-API function calls on the same `env`. This includes a call to `napi_is_exception_pending()`. So here it is necessary to make a copy of the information as the `error_code` field is used later on. Fixes: nodejs#1089 Signed-off-by: Darshan Sen <darshan.sen@postman.com>
PR: #1092 |
All fields of the `napi_extended_error_info` structure gets reset in subsequent Node-API function calls on the same `env`. This includes a call to `napi_is_exception_pending()`. So here it is necessary to make a copy of the information as the `error_code` field is used later on. Fixes: nodejs#1089 Signed-off-by: Darshan Sen <darshan.sen@postman.com>
Fix up example and make it more explicit on how you need to use napi_extended_error_info in order to help people avoid what might be a common mistake that we made in node-addon-api. Refs: nodejs/node-addon-api#1089 Signed-off-by: Michael Dawson <mdawson@devrus.com> PR-URL: #40458 Reviewed-By: Gabriel Schulhof <gabrielschulhof@gmail.com> Reviewed-By: Darshan Sen <raisinten@gmail.com>
Currently working on a PR to reset the error info if previous status is |
Fix up example and make it more explicit on how you need to use napi_extended_error_info in order to help people avoid what might be a common mistake that we made in node-addon-api. Refs: nodejs/node-addon-api#1089 Signed-off-by: Michael Dawson <mdawson@devrus.com> PR-URL: #40458 Reviewed-By: Gabriel Schulhof <gabrielschulhof@gmail.com> Reviewed-By: Darshan Sen <raisinten@gmail.com>
PR-URL: #40552 Refs: nodejs/node-addon-api#1089 Reviewed-By: Darshan Sen <raisinten@gmail.com> Reviewed-By: James M Snell <jasnell@gmail.com> Reviewed-By: Michael Dawson <midawson@redhat.com> Reviewed-By: Gabriel Schulhof <gabrielschulhof@gmail.com> Reviewed-By: Juan José Arboleda <soyjuanarbol@gmail.com>
PR-URL: #40552 Refs: nodejs/node-addon-api#1089 Reviewed-By: Darshan Sen <raisinten@gmail.com> Reviewed-By: James M Snell <jasnell@gmail.com> Reviewed-By: Michael Dawson <midawson@redhat.com> Reviewed-By: Gabriel Schulhof <gabrielschulhof@gmail.com> Reviewed-By: Juan José Arboleda <soyjuanarbol@gmail.com>
Fix up example and make it more explicit on how you need to use napi_extended_error_info in order to help people avoid what might be a common mistake that we made in node-addon-api. Refs: nodejs/node-addon-api#1089 Signed-off-by: Michael Dawson <mdawson@devrus.com> PR-URL: #40458 Reviewed-By: Gabriel Schulhof <gabrielschulhof@gmail.com> Reviewed-By: Darshan Sen <raisinten@gmail.com>
PR-URL: #40552 Refs: nodejs/node-addon-api#1089 Reviewed-By: Darshan Sen <raisinten@gmail.com> Reviewed-By: James M Snell <jasnell@gmail.com> Reviewed-By: Michael Dawson <midawson@redhat.com> Reviewed-By: Gabriel Schulhof <gabrielschulhof@gmail.com> Reviewed-By: Juan José Arboleda <soyjuanarbol@gmail.com>
PR-URL: #40552 Refs: nodejs/node-addon-api#1089 Reviewed-By: Darshan Sen <raisinten@gmail.com> Reviewed-By: James M Snell <jasnell@gmail.com> Reviewed-By: Michael Dawson <midawson@redhat.com> Reviewed-By: Gabriel Schulhof <gabrielschulhof@gmail.com> Reviewed-By: Juan José Arboleda <soyjuanarbol@gmail.com>
All fields of the `napi_extended_error_info` structure gets reset in subsequent Node-API function calls on the same `env`. This includes a call to `napi_is_exception_pending()`. So here it is necessary to make a copy of the information as the `error_code` field is used later on. Signed-off-by: Darshan Sen <darshan.sen@postman.com> PR-URL: nodejs/node-addon-api#1092 Fixes: nodejs/node-addon-api#1089 Reviewed-By: Michael Dawson <michael_dawson@ca.ibm.com>
All fields of the `napi_extended_error_info` structure gets reset in subsequent Node-API function calls on the same `env`. This includes a call to `napi_is_exception_pending()`. So here it is necessary to make a copy of the information as the `error_code` field is used later on. Signed-off-by: Darshan Sen <darshan.sen@postman.com> PR-URL: nodejs/node-addon-api#1092 Fixes: nodejs/node-addon-api#1089 Reviewed-By: Michael Dawson <michael_dawson@ca.ibm.com>
All fields of the `napi_extended_error_info` structure gets reset in subsequent Node-API function calls on the same `env`. This includes a call to `napi_is_exception_pending()`. So here it is necessary to make a copy of the information as the `error_code` field is used later on. Signed-off-by: Darshan Sen <darshan.sen@postman.com> PR-URL: nodejs/node-addon-api#1092 Fixes: nodejs/node-addon-api#1089 Reviewed-By: Michael Dawson <michael_dawson@ca.ibm.com>
All fields of the `napi_extended_error_info` structure gets reset in subsequent Node-API function calls on the same `env`. This includes a call to `napi_is_exception_pending()`. So here it is necessary to make a copy of the information as the `error_code` field is used later on. Signed-off-by: Darshan Sen <darshan.sen@postman.com> PR-URL: nodejs/node-addon-api#1092 Fixes: nodejs/node-addon-api#1089 Reviewed-By: Michael Dawson <michael_dawson@ca.ibm.com>
I was writing a small Cpp addon trying to see if there exists a scenario where the
_ref
class variable ofError
class might be a nullptr.Since it looks like the error_code
napi_boolean_expected
isn't handled by the switch statement insideError::New()
.Though it looks like even though we are able to retrieve the error info using
napi_get_last_error_info
, once we callnapi_is_exception_pending
we will clear the last error and thus lose the error info from the previous invocation.I am just wondering if this is the expected behaviour? Since it looks like the original error info( a const) is intended to be used elsewhere in the function body. Thanks!
The text was updated successfully, but these errors were encountered: