doc: remove spaces around slashes
Remove spaces around slash characters in documentation. This change sometimes rewords the content where the slash construction may not be what is called for. PR-URL: https://github.com/nodejs/node/pull/21140 Reviewed-By: Vse Mozhet Byt <vsemozhetbyt@gmail.com> Reviewed-By: Michaël Zasso <targos@protonmail.com> Reviewed-By: Trivikram Kamat <trivikr.dev@gmail.com> Reviewed-By: Colin Ihrig <cjihrig@gmail.com>
This commit is contained in:
parent
25c92a9026
commit
85fe134026
@ -1083,7 +1083,7 @@ validating against a string property. See below for examples.
|
||||
If specified, `message` will be the message provided by the `AssertionError` if
|
||||
the block fails to throw.
|
||||
|
||||
Custom validation object / error instance:
|
||||
Custom validation object/error instance:
|
||||
|
||||
```js
|
||||
const err = new TypeError('Wrong value');
|
||||
|
@ -2268,7 +2268,7 @@ mode must adhere to certain restrictions when using the cipher API:
|
||||
bytes (`7 ≤ N ≤ 13`).
|
||||
- The length of the plaintext is limited to `2 ** (8 * (15 - N))` bytes.
|
||||
- When decrypting, the authentication tag must be set via `setAuthTag()` before
|
||||
specifying additional authenticated data and / or calling `update()`.
|
||||
specifying additional authenticated data or calling `update()`.
|
||||
Otherwise, decryption will fail and `final()` will throw an error in
|
||||
compliance with section 2.6 of [RFC 3610][].
|
||||
- Using stream methods such as `write(data)`, `end(data)` or `pipe()` in CCM
|
||||
@ -2278,8 +2278,8 @@ mode must adhere to certain restrictions when using the cipher API:
|
||||
option. This is not necessary if no AAD is used.
|
||||
- As CCM processes the whole message at once, `update()` can only be called
|
||||
once.
|
||||
- Even though calling `update()` is sufficient to encrypt / decrypt the message,
|
||||
applications *must* call `final()` to compute and / or verify the
|
||||
- Even though calling `update()` is sufficient to encrypt/decrypt the message,
|
||||
applications *must* call `final()` to compute or verify the
|
||||
authentication tag.
|
||||
|
||||
```js
|
||||
|
@ -1,4 +1,4 @@
|
||||
# UDP / Datagram Sockets
|
||||
# UDP/Datagram Sockets
|
||||
|
||||
<!--introduced_in=v0.10.0-->
|
||||
|
||||
|
@ -499,8 +499,8 @@ will be present on the object:
|
||||
|
||||
| Type | Properties |
|
||||
|------|------------|
|
||||
| `'A'` | `address` / `ttl` |
|
||||
| `'AAAA'` | `address` / `ttl` |
|
||||
| `'A'` | `address`/`ttl` |
|
||||
| `'AAAA'` | `address`/`ttl` |
|
||||
| `'CNAME'` | `value` |
|
||||
| `'MX'` | Refer to [`dns.resolveMx()`][] |
|
||||
| `'NAPTR'` | Refer to [`dns.resolveNaptr()`][] |
|
||||
|
@ -31,7 +31,7 @@ called.
|
||||
|
||||
All JavaScript errors are handled as exceptions that *immediately* generate
|
||||
and throw an error using the standard JavaScript `throw` mechanism. These
|
||||
are handled using the [`try / catch` construct][try-catch] provided by the
|
||||
are handled using the [`try…catch` construct][try-catch] provided by the
|
||||
JavaScript language.
|
||||
|
||||
```js
|
||||
@ -45,7 +45,7 @@ try {
|
||||
```
|
||||
|
||||
Any use of the JavaScript `throw` mechanism will raise an exception that
|
||||
*must* be handled using `try / catch` or the Node.js process will exit
|
||||
*must* be handled using `try…catch` or the Node.js process will exit
|
||||
immediately.
|
||||
|
||||
With few exceptions, _Synchronous_ APIs (any blocking method that does not
|
||||
@ -90,7 +90,7 @@ Errors that occur within _Asynchronous APIs_ may be reported in multiple ways:
|
||||
|
||||
- A handful of typically asynchronous methods in the Node.js API may still
|
||||
use the `throw` mechanism to raise exceptions that must be handled using
|
||||
`try / catch`. There is no comprehensive list of such methods; please
|
||||
`try…catch`. There is no comprehensive list of such methods; please
|
||||
refer to the documentation of each method to determine the appropriate
|
||||
error handling mechanism required.
|
||||
|
||||
@ -116,7 +116,7 @@ setImmediate(() => {
|
||||
});
|
||||
```
|
||||
|
||||
Errors generated in this way *cannot* be intercepted using `try / catch` as
|
||||
Errors generated in this way *cannot* be intercepted using `try…catch` as
|
||||
they are thrown *after* the calling code has already exited.
|
||||
|
||||
Developers must refer to the documentation for each method to determine
|
||||
@ -149,7 +149,7 @@ fs.readFile('/some/file/that/does-not-exist', errorFirstCallback);
|
||||
fs.readFile('/some/file/that/does-exist', errorFirstCallback);
|
||||
```
|
||||
|
||||
The JavaScript `try / catch` mechanism **cannot** be used to intercept errors
|
||||
The JavaScript `try…catch` mechanism **cannot** be used to intercept errors
|
||||
generated by asynchronous APIs. A common mistake for beginners is to try to
|
||||
use `throw` inside an error-first callback:
|
||||
|
||||
@ -648,7 +648,7 @@ Used when a child process is being forked without specifying an IPC channel.
|
||||
### ERR_CHILD_PROCESS_STDIO_MAXBUFFER
|
||||
|
||||
Used when the main process is trying to read data from the child process's
|
||||
STDERR / STDOUT, and the data's length is longer than the `maxBuffer` option.
|
||||
STDERR/STDOUT, and the data's length is longer than the `maxBuffer` option.
|
||||
|
||||
<a id="ERR_CLOSED_MESSAGE_PORT"></a>
|
||||
### ERR_CLOSED_MESSAGE_PORT
|
||||
|
@ -36,7 +36,7 @@ To control how ICU is used in Node.js, four `configure` options are available
|
||||
during compilation. Additional details on how to compile Node.js are documented
|
||||
in [BUILDING.md][].
|
||||
|
||||
- `--with-intl=none` / `--without-intl`
|
||||
- `--with-intl=none`/`--without-intl`
|
||||
- `--with-intl=system-icu`
|
||||
- `--with-intl=small-icu` (default)
|
||||
- `--with-intl=full-icu`
|
||||
|
@ -213,7 +213,7 @@ called. Otherwise, an `ERR_SERVER_ALREADY_LISTEN` error will be thrown.
|
||||
|
||||
One of the most common errors raised when listening is `EADDRINUSE`.
|
||||
This happens when another server is already listening on the requested
|
||||
`port` / `path` / `handle`. One way to handle this would be to retry
|
||||
`port`/`path`/`handle`. One way to handle this would be to retry
|
||||
after a certain amount of time:
|
||||
|
||||
```js
|
||||
|
@ -367,7 +367,7 @@ added: v8.0.0
|
||||
|
||||
Destroy the stream, and emit the passed `'error'` and a `'close'` event.
|
||||
After this call, the writable stream has ended and subsequent calls
|
||||
to `write()` / `end()` will give an `ERR_STREAM_DESTROYED` error.
|
||||
to `write()` or `end()` will result in an `ERR_STREAM_DESTROYED` error.
|
||||
Implementors should not override this method,
|
||||
but instead implement [`writable._destroy()`][writable-_destroy].
|
||||
|
||||
|
Loading…
x
Reference in New Issue
Block a user