-
Notifications
You must be signed in to change notification settings - Fork 30k
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
n-api error status discussion #29849
Comments
If there is an exception pending (whether it was just thrown or not) but no other error then napi_pending_exception should be returned. If there is a pending exception it is still ok to return a more specific error. The docs say that in addition to handling that error you must still check for a pending exception. Generally I think we should avoid N-API itself throwing an exception and instead have it return an error. So for:
Either is actually legal. I'd have to look at the specific cases to see if one made more sense than another but my take would be napi_generic_failure as N-API should generally be returning an error as opposed to throwing an exception and returning an error is at least a bit more consistent with that. |
@legendecas ideally
Unfortunately, we have not been very consistent in maintaining this principle as we've moved N-API forward 😕 For example, in CHECK_MAYBE_EMPTY(env, get_maybe, napi_generic_failure); Before returning We have quite a few inconsistencies like these in the implementation. |
So for question 2:
Could we get into a summary that throwing in N-API shall be prevented from and preferring returning an error napi_status? For condition of which status shall be returned depends on the case specifically. Likewise, napi_pending_exception shall be preferred if the exception was thrown by the engine. And napi_generic_failure shall be considered in most conditions. On the statement above, napi_status enum might get appended every time we have a new error condition. E.g. in #29768 two new napi_status were added. Though I am not much uncomfortable with a big enum of napi_status. Would it be concerning anyone? |
@legendecas that sounds like a good summary 👍 I don't think there's any problem with a large enum. |
I'm not worried about too big an enum either, although I'm not sure it will get all that big anyway. |
Just reviewing the error handling in node-addon-api. I noticed that the thrown error in N-APIs with non- So I updated #29847 to correct the related parts. PTAL :) |
@legendecas that sounds like a good summary 👍 I don't think there's any problem with a large enum.
Absolutely!
I don't believe a big enum should be a concern. We have many error scenarios and we should be able to distinguish between them. The only constraint is that whatever we have today, and however inconsistent it is, must remain so, because we must not introduce breaking changes. |
N-API statuses shall be preferred over throwing JavaScript Errors on checks occurred in N-APIs. PR-URL: #31312 Refs: #29849 Reviewed-By: Anna Henningsen <[email protected]> Reviewed-By: Colin Ihrig <[email protected]> Reviewed-By: Tobias Nießen <[email protected]> Reviewed-By: Ruben Bridgewater <[email protected]> Reviewed-By: Rich Trott <[email protected]> Reviewed-By: Michael Dawson <[email protected]>
N-API statuses shall be preferred over throwing JavaScript Errors on checks occurred in N-APIs. PR-URL: #31312 Refs: #29849 Reviewed-By: Anna Henningsen <[email protected]> Reviewed-By: Colin Ihrig <[email protected]> Reviewed-By: Tobias Nießen <[email protected]> Reviewed-By: Ruben Bridgewater <[email protected]> Reviewed-By: Rich Trott <[email protected]> Reviewed-By: Michael Dawson <[email protected]>
N-API statuses shall be preferred over throwing JavaScript Errors on checks occurred in N-APIs. PR-URL: #31312 Refs: #29849 Reviewed-By: Anna Henningsen <[email protected]> Reviewed-By: Colin Ihrig <[email protected]> Reviewed-By: Tobias Nießen <[email protected]> Reviewed-By: Ruben Bridgewater <[email protected]> Reviewed-By: Rich Trott <[email protected]> Reviewed-By: Michael Dawson <[email protected]>
N-API statuses shall be preferred over throwing JavaScript Errors on checks occurred in N-APIs. PR-URL: #31312 Refs: #29849 Reviewed-By: Anna Henningsen <[email protected]> Reviewed-By: Colin Ihrig <[email protected]> Reviewed-By: Tobias Nießen <[email protected]> Reviewed-By: Ruben Bridgewater <[email protected]> Reviewed-By: Rich Trott <[email protected]> Reviewed-By: Michael Dawson <[email protected]>
@legendecas what's the status of this issue? |
This PR has no further action to take. Closing for now. |
We could find out that there are several napi_status existing and been used in various n-api functions.
napi_ok
:For any n-api call that is successful.
napi_cancelled
For canceled async works.
napi_escape_called_twice
napi_handle_scope_mismatch
napi_callback_scope_mismatch
For handle scope error conditions.
napi_queue_full
napi_closing
For ThreadSafeFunction error conditions.
napi_invalid_arg
This is what I'd like to discuss about. If I got it right, mostly, invalid args of calling of n-api should get into this status, except following type exceptions (mostly JavaScript primitive values, but
array
anddate
are not,name
is a virtual type that is defined in ECMA spec):napi_object_expected
napi_string_expected
napi_name_expected
napi_function_expected
napi_instanceof
: would throw JavaScript TypeError if constructor is not a function, and return anapi_function_expected
status.napi_number_expected
napi_boolean_expected
napi_array_expected
napi_bigint_expected
napi_date_expected
Except for all above statuses, following two is additional generic error status:
napi_generic_failure
This could be used in most places IMO, but it has been mixed up with
napi_pending_exception
in some conditions:THROW_RANGE_ERROR_IF_FALSE
returnsnapi_generic_failure
with throwing JavaScript RangeError.napi_create_bigint_words
returnsnapi_pending_exception
with throwing JavaScript TypeError.napi_instanceof
returnsnapi_function_expected
with throwing JavaScript TypeError.napi_create_dataview
returnsnapi_pending_exception
with throwing JavaScript RangeError.napi_pending_exception
For any n-api call that has pending JavaScript Exception. If I understand n-api document right, every non-
napi_ok
status should throw a JavaScript exception, andnapi_pending_exception
should be used if the previous JavaScript exception was not handled while calling sequent n-apis.So here comes the unresolved questions:
napi_is_<typename>
function?napi_generic_failure
ornapi_pending_exception
?Refs: #29768 (comment)
Related: #29847
/cc @gabrielschulhof @mhdawson
The text was updated successfully, but these errors were encountered: