Skip to content
New issue

Have a question about this project? # for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “#”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? # to your account

doc: remove personal pronouns from API doc #23347

Closed
wants to merge 3 commits into from
Closed
Show file tree
Hide file tree
Changes from all commits
Commits
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
2 changes: 1 addition & 1 deletion doc/api/domain.md
Original file line number Diff line number Diff line change
Expand Up @@ -38,7 +38,7 @@ Domain error handlers are not a substitute for closing down a
process when an error occurs.

By the very nature of how [`throw`][] works in JavaScript, there is almost
never any way to safely "pick up where you left off", without leaking
never any way to safely "pick up where it left off", without leaking
references, or creating some other sort of undefined brittle state.

The safest way to respond to a thrown error is to shut down the
Expand Down
8 changes: 4 additions & 4 deletions doc/api/process.md
Original file line number Diff line number Diff line change
Expand Up @@ -114,7 +114,7 @@ The `'multipleResolves'` event is emitted whenever a `Promise` has been either:
* Rejected after resolve.
* Resolved after reject.

This is useful for tracking errors in your application while using the promise
This is useful for tracking errors in an application while using the promise
constructor. Otherwise such mistakes are silently swallowed due to being in a
dead zone.

Expand Down Expand Up @@ -207,9 +207,9 @@ exception bubbles all the way back to the event loop. By default, Node.js
handles such exceptions by printing the stack trace to `stderr` and exiting
with code 1, overriding any previously set [`process.exitCode`][].
Adding a handler for the `'uncaughtException'` event overrides this default
behavior. You may also change the [`process.exitCode`][] in
`'uncaughtException'` handler which will result in process exiting with
provided exit code, otherwise in the presence of such handler the process will
behavior. Alternatively, change the [`process.exitCode`][] in the
`'uncaughtException'` handler which will result in the process exiting with the
provided exit code. Otherwise, in the presence of such handler the process will
exit with 0.

The listener function is called with the `Error` object passed as the only
Expand Down
10 changes: 5 additions & 5 deletions doc/api/worker_threads.md
Original file line number Diff line number Diff line change
Expand Up @@ -154,8 +154,8 @@ added: v10.5.0
-->

Disables further sending of messages on either side of the connection.
This method can be called once you know that no further communication
will happen over this `MessagePort`.
This method can be called when no further communication will happen over this
`MessagePort`.

### port.postMessage(value[, transferList])
<!-- YAML
Expand Down Expand Up @@ -436,9 +436,9 @@ to have completed.

**Warning**: Currently, not all code in the internals of Node.js is prepared to
expect termination at arbitrary points in time and may crash if it encounters
that condition. Consequently, you should currently only call `.terminate()` if
it is known that the Worker thread is not accessing Node.js core modules other
than what is exposed in the `worker` module.
that condition. Consequently, only call `.terminate()` if it is known that the
Worker thread is not accessing Node.js core modules other than what is exposed
in the `worker` module.

### worker.threadId
<!-- YAML
Expand Down