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.

Sign up for GitHub

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

Jump to bottom

doc: add clarification for exception behaviour #25339

Closed
wants to merge 6 commits into from
Closed

doc: add clarification for exception behaviour #25339

Changes from 1 commit
Commits
Show all changes
6 commits
Select commit Hold shift + click to select a range
79bc97c
doc: add clarification for exception behaviour
mhdawson Jan 4, 2019
9b16424
Update doc/api/n-api.md
Trott Jan 7, 2019
b4783ca
squash: accept suggestion
Trott Jan 7, 2019
73fa299
squash: accept suggestion
Trott Jan 7, 2019
450ee9c
squash: address comments
mhdawson Jan 7, 2019
39b0ca3
squash: fixup line formatting after changes.
mhdawson Jan 7, 2019
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
11 changes: 11 additions & 0 deletions doc/api/n-api.md
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -527,6 +527,17 @@ exception is pending and no additional action is required. If the
instead of simply returning immediately, [`napi_is_exception_pending`][]
must be called in order to determine if an exception is pending or not.

In many cases when an N-API function is called and an exception is
already pending the function will return immediately with a
mhdawson marked this conversation as resolved.
Show resolved Hide resolved
`napi_status` of `napi_pending_exception`. However, this is not the case
for all functions. N-API allows a subset of the functions to be
called in order to allow for some minimal cleanup to be completed
mhdawson marked this conversation as resolved.
Show resolved Hide resolved
before returning to JavaScript. For those functions, `napi_status`
will reflect the success/error/exception for that function, irrespective of
whether an exception was pending when the function was called.
Copy link
Member

Choose a reason for hiding this comment

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

This sentence is difficult to understand. "for that function" is particularly confusing coming after "for those functions". Maybe try writing it as two shorter sentences or something? Or just tidying up the sentence that's there somehow?

Copy link
Member

Choose a reason for hiding this comment

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

Maybe something like this?

In that case, `napi_status` will reflect the status for the function.
It will not reflect previous pending exceptions.

Copy link
Member

Choose a reason for hiding this comment

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

(Obviously, change my suggestion if it is factually incorrect. I'm commenting on style and readability, not content.)

Copy link
Member Author

Choose a reason for hiding this comment

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

Your suggestion works for me. Updating.

In order to avoid confusion it is important to check the
mhdawson marked this conversation as resolved.
Show resolved Hide resolved
error status after every function call.

When an exception is pending one of two approaches can be employed.

The first approach is to do any appropriate cleanup and then return so that
Expand Down