-
Notifications
You must be signed in to change notification settings - Fork 29.6k
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
doc: add and fix System Error properties #10986
Conversation
doc/api/errors.md
Outdated
@@ -459,10 +459,27 @@ Returns a number corresponding to the **negated** error code, which may be | |||
referenced in `man 2 intro`. For example, an `ENOENT` error has an `errno` of | |||
`-2` because the error code for `ENOENT` is `2`. | |||
|
|||
In some mudules, returns the same string as `error.code`. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
s/mudules/modules/
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@mscdex Thanks for your review.
doc/api/errors.md
Outdated
#### error.syscall | ||
|
||
Returns a string describing the [syscall][] that failed. | ||
|
||
#### error.path | ||
|
||
Returns a string of the specified invalid pathname in case of using some modules |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Despite the term 'returns' being better suited for functions rather than properties, this would still be better wording IMHO: 'Returns a string containing the relevant invalid pathname (where applicable).'
Similarly for the other properties added below.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Even though there are existing contrary examples in this very file, I think we should avoid saying returns
when talking about a property. We should reserve returns
for functions.
So, instead of Returns a string that...
, just A string that...
. Yes, it will technically be a sentence fragment, but I think it's acceptable in this case. It would certainly be clear and understandable which is the most important thing.
/cc @nodejs/documentation
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I feel like a simple s/returns/is/ would make sense, in most cases.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Hate to disagree with @Qard, but -1 on this approach. We don't start descriptions with Is
anywhere else in the docs. Let's not create a third way to do things. Let's standardize on one of the existing approaches.
IMO, this should be: A string of the specified invalid pathname in case of using some modules...
rather than Is a string of the specified...
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'm good either way. Just figured "is" might provide a better hint as to the access method.
About the following expression as well, not 'returns' but 'is' may be better. |
doc/api/errors.md
Outdated
referenced in `man 2 intro`. For example, an `ENOENT` error has an `errno` of | ||
`-2` because the error code for `ENOENT` is `2`. | ||
|
||
In some modules, this property is the same string as `error.code`. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
'Same string?' Above it is mentioned that this is a number, not a string.
doc/api/errors.md
Outdated
|
||
#### error.path | ||
|
||
Is a string of the specified invalid pathname in case of using some modules |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
'the specified' here is confusing. It makes it sound like it's a value the user is passing into a function or something. As previously suggested, I would use something like:
Is a string containing a relevant invalid path name (where applicable). Some modules that include this property are
fs
andchild_process
.
and structuring the other two property descriptions similarly.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@mscdex
I understood. I will fix.
doc/api/errors.md
Outdated
referenced in `man 2 intro`. For example, an `ENOENT` error has an `errno` of | ||
`-2` because the error code for `ENOENT` is `2`. | ||
|
||
In some modules, this property is the same string as `error.code`. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I know, its miserable trying to figure exactly which modules do this, but this doc reads as "behaviour is random, shrug". Consider giving some advice on what to do:
const errno = error.errno || error.code;
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
That may not be preferrable if errno
is a number, whereas code
is a string? You'd have to explicitly cast to a string.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
OK, then the docs should say "In some modules, is a number corresponding to ...etc." because the first sentence is being contradicted by the paragraph after ATM.
Is there an open issue to track this? It doesn't strike me as so helpful to sometimes be an "E" string, and sometimes a number.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'm not familiar enough with the libuv error codes, but I would guess that the .code
would be the same across platforms whereas the .errno
may not be?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I heard this from @darai0512 a few days ago and also was surprised to know that.
I think we cannot change them for there are codes expecting errno is string.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think it is better to fix like this. How is it?
--- a/doc/api/errors.md
+++ b/doc/api/errors.md
@@ -455,9 +455,11 @@ a sequence of capital letters, and may be referenced in `man 2 intro`.
#### error.errno
-Returns a number corresponding to the **negated** error code, which may be
-referenced in `man 2 intro`. For example, an `ENOENT` error has an `errno` of
-`-2` because the error code for `ENOENT` is `2`.
+Returns a number or a string. The number corresponds to the
+**negated** error code, which may be referenced in `man 2 intro`. For
+example, an `ENOENT` error has an `errno` of `-2` because the error
+code for `ENOENT` is `2`.
+In case of a string, it is the same as error.code
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I will modify it according to @shigeki advise.
doc/api/errors.md
Outdated
|
||
#### error.address | ||
|
||
Is a string describing the address that is not available in case of using some |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
"When present, "....
Is it always an address that is not available? Can't it show up in errors for other reasons?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This appears only in the error that comes from net and dgram. I think that is why it was missed in the doc. I told him to add what modules it happens in. How about this?
When present (e.g. in net and dgram), it is a string describing the address that is not available.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
OK, I will fix.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I like@shigeki's text, but I'm not sure what "not available means". It means that the address cannot be looked up?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@sam-github
Exactly, so I rewrite the description. Please review.
doc/api/errors.md
Outdated
|
||
#### error.port | ||
|
||
Is a number of the connection's port that is refused in case of using some |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Doesn't it show for other reasons, such as connection reset?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
"When present, ..."
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Doesn't it show for other reasons, such as connection reset?
Exactly. The same description of error.address as is not available
seems to be better.
doc/api/errors.md
Outdated
#### error.syscall | ||
|
||
Returns a string describing the [syscall][] that failed. | ||
Is a string describing the [syscall][] that failed. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
"When present, ..."
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@sam-github
Excuse me, is there some cases without error.syscall property?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Almost there. It may also be worth documenting the error.name
property.
doc/api/errors.md
Outdated
@@ -250,7 +250,7 @@ not capture any frames. | |||
|
|||
#### error.message | |||
|
|||
Returns the string description of error as set by calling `new Error(message)`. | |||
Is the string description of error as set by calling `new Error(message)`. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I would prefer something like:
The `error.message` property is the...
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@jasnell Thanks for your review. I will fix.
doc/api/errors.md
Outdated
@@ -250,7 +250,7 @@ not capture any frames. | |||
|
|||
#### error.message | |||
|
|||
Returns the string description of error as set by calling `new Error(message)`. | |||
Is the string description of error as set by calling `new Error(message)`. | |||
The `message` passed to the constructor will also appear in the first line of | |||
the stack trace of the `Error`, however changing this property after the | |||
`Error` object is created *may not* change the first line of the stack trace. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
We should be clear here. I know this was already in the doc, but may not is not that clear. We should say whether it will or will not or indicate the conditions under which it may or may not.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I also got confused about its expression.
I know a simple example such as the following code.
Error.stackTraceLimit = 0;
var error = new Error('This will not change');
console.log(error.stack);
// Prints: Error: This will not change
error.message = 'not changed';
console.log(error.stack);
// Prints: Error: This will not change
Error.stackTraceLimit = 0;
var error = new Error('This will change');
error.message = 'changed';
console.log(error.stack);
// Prints: Error: changed
So, I will add the statement of (for example, when error.stack is set before this property is changed)
I think So, I think there is no necessity to explain it here. How about? |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
other than that the man page ref seems wrong on linux, LGTM
doc/api/errors.md
Outdated
Returns a string representing the error code, which is always `E` followed by | ||
a sequence of capital letters, and may be referenced in `man 2 intro`. | ||
The `error.code` property is a string representing the error code, which is always | ||
`E` followed by a sequence of capital letters, and may be referenced in `man 2 intro`. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I don't see them refed on linux in the syscall intro, I do see them in man 3 errno
.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@sam-github
Exactly. The command is already explained. So, I think there is no necessity to explain it here and in error.errno.
https://github.com/darai0512/node/blame/85341c7ae573c31c43ce05549e8f789138e047fd/doc/api/errors.md#L445-L446
This is close to ready, can you squash and rebase please? |
doc/api/errors.md
Outdated
The `message` passed to the constructor will also appear in the first line of | ||
the stack trace of the `Error`, however changing this property after the | ||
`Error` object is created *may not* change the first line of the stack trace. | ||
`Error` object is created *may not* change the first line of the stack trace | ||
(for example, when error.stack is set before this property is changed). |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
'error.stack' here should have backticks around it.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
OK, I will fix: error.stack -> error.stack
doc/api/errors.md
Outdated
The number corresponds to the **negated** error code, which may be referenced in | ||
`man 2 intro`. For example, an `ENOENT` error has an `errno` of `-2` because the | ||
error code for `ENOENT` is `2`. | ||
In case of a string, it is the same as error.code. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
'error.code' here should be surrounded by backticks.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
OK, I will fix: error.code -> error.code
doc/api/errors.md
Outdated
referenced in `man 2 intro`. For example, an `ENOENT` error has an `errno` of | ||
`-2` because the error code for `ENOENT` is `2`. | ||
The `error.errno` property is a number or a string. | ||
The number corresponds to the **negated** error code, which may be referenced in |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Might want to double-check the applicability of this information to Windows systems ...
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I fix about the command. I think it is already explained in L445-446, so there is no necessity to explain it again.
running
man 2 intro
orman 3 errno
on most Unices; or [online][].
But exactly, it may not be referred to Windows systems.
I think 'online' is covered about it. How about?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I wasn't referring to the man
reference, but instead the information about the error code being negated and such (e.g. the number may be positive on Windows from the start? is the number from the man pages still relevant for Windows -- does libuv normalize them on Windows?).
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Sorry, I understood your point. The errno of this example may not be -2
on Windows. I will look over......
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@mscdex Good catch. Right, the Windows error is mapped to libuv error in https://github.com/nodejs/node/blob/master/deps/uv/src/win/error.c#L66 then allocated to an arbitrary negative number in uv-errno.h
. I think that it is better not to describe this further here but just put reference to libuv.
diff --git a/doc/api/errors.md b/doc/api/errors.md
index 86d06fa..9a72cc9 100644
--- a/doc/api/errors.md
+++ b/doc/api/errors.md
@@ -458,9 +458,10 @@ The `error.code` property is a string representing the error code, which is alwa
#### error.errno
The `error.errno` property is a number or a string.
-The number corresponds to the **negated** error code. For example, an `ENOENT`
-error has an `errno` of `-2` because the error code for `ENOENT` is `2`.
-In case of a string, it is the same as `error.code`.
+The number corresponds to the **negated** error code which is defined
+in [`libuv Error handling`]. See uv-errno.h header file
+(`deps/uv/include/uv-errno.h` in the Node.js source tree) for
+details. In case of a string, it is the same as `error.code`.
#### error.syscall
@@ -546,6 +547,7 @@ found [here][online].
[`fs`]: fs.html
[`http`]: http.html
[`https`]: https.html
+[`libuv Error handling`]: http://docs.libuv.org/en/v1.x/errors.html
[`net`]: net.html
[`process.on('uncaughtException')`]: process.html#process_event_uncaughtexception
[domains]: domain.html
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@mscdex PTAL
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@darai0512 It still shows the old text for this property?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@darai0512 My last proposal is
The `error.errno` property is a number or a string.
The number is a **negative** value which corresponds to the error code
defined in [`libuv Error handling`]. See uv-errno.h header file
(`deps/uv/include/uv-errno.h` in the Node.js source tree) for
details. In case of a string, it is the same as `error.code`.
The current your commit does not have it.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@sam-github |
@mscdex had comments and needs to review |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
While you are at it, please also add type annotations (like the ones in http)
doc/api/errors.md
Outdated
@@ -250,10 +250,12 @@ not capture any frames. | |||
|
|||
#### error.message | |||
|
|||
Returns the string description of error as set by calling `new Error(message)`. | |||
The `error.message` property is the string description of error as set by calling | |||
`new Error(message)`. | |||
The `message` passed to the constructor will also appear in the first line of |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
There should be either a paragraph break, or the lines should be wrapped together. It's not immediately clear what this is trying to do.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Okay, I will change it to 1 line.
doc/api/errors.md
Outdated
The `message` passed to the constructor will also appear in the first line of | ||
the stack trace of the `Error`, however changing this property after the | ||
`Error` object is created *may not* change the first line of the stack trace. | ||
`Error` object is created *may not* change the first line of the stack trace | ||
(for example, when `error.stack` is set before this property is changed). |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Can you elaborate on when error.stack
is "set"?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I thought "called" was good at first. But it is good for not property but function.
"read" is good?
doc/api/errors.md
Outdated
`-2` because the error code for `ENOENT` is `2`. | ||
The `error.errno` property is a number or a string. | ||
The number corresponds to the **negated** error code. For example, an `ENOENT` | ||
error has an `errno` of `-2` because the error code for `ENOENT` is `2`. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Is ENOENT
guaranteed to be 2
on all platforms by a specification? Or is it true de facto?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
No, it may vary either on unix or on win32. @mscdex also refers to it. I will check it...
doc/api/errors.md
Outdated
#### error.port | ||
|
||
When present (e.g. in `net` or `dgram`), the `error.port` property is a number of | ||
the connection's port that is not available. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
"port that is not available" sounds too specific to me. Is port binding the only case in Node.js when err.port
is present? Either way, I'd prefer "a relevant port number", which is intentionally vague but more future-proof.
Also, "... property is a number representing ..." sounds slightly better.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thanks for your review. I will fix the following text.
=> the error.port
property is a number representing the connection's port that is not available.
@TimothyGu PTAL |
doc/api/errors.md
Outdated
Returns the string description of error as set by calling `new Error(message)`. | ||
* {String} | ||
|
||
The `error.message` property is the string description of error as set by calling `new Error(message)`. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
s/of error/of the error/ or add backticks around 'error'
PTAL |
05d3541
to
baaf148
Compare
Sorry, I made a mistake about @shigeki 's proposal. So, I fixed it. |
About path, address and port properties, these are not described though being also represented as augmented Error objects with added properties. And also, fix all property descriptions and add type annotations.
About path, address and port properties, these are not described though being also represented as augmented Error objects with added properties. And also, fix all property descriptions and add type annotations. PR-URL: #10986 Reviewed-By: James M Snell <jasnell@gmail.com> Reviewed-By: Sam Roberts <vieuxtech@gmail.com>
Landed in fcedd71 |
About path, address and port properties, these are not described though being also represented as augmented Error objects with added properties. And also, fix all property descriptions and add type annotations. PR-URL: nodejs#10986 Reviewed-By: James M Snell <jasnell@gmail.com> Reviewed-By: Sam Roberts <vieuxtech@gmail.com>
About path, address and port properties, these are not described though being also represented as augmented Error objects with added properties. And also, fix all property descriptions and add type annotations. PR-URL: nodejs#10986 Reviewed-By: James M Snell <jasnell@gmail.com> Reviewed-By: Sam Roberts <vieuxtech@gmail.com>
About path, address and port properties, these are not described though being also represented as augmented Error objects with added properties. And also, fix all property descriptions and add type annotations. PR-URL: nodejs#10986 Reviewed-By: James M Snell <jasnell@gmail.com> Reviewed-By: Sam Roberts <vieuxtech@gmail.com>
About path, address and port properties, these are not described though being also represented as augmented Error objects with added properties. And also, fix all property descriptions and add type annotations. PR-URL: #10986 Reviewed-By: James M Snell <jasnell@gmail.com> Reviewed-By: Sam Roberts <vieuxtech@gmail.com>
About path, address and port properties, these are not described though being also represented as augmented Error objects with added properties. And also, fix all property descriptions and add type annotations. PR-URL: #10986 Reviewed-By: James M Snell <jasnell@gmail.com> Reviewed-By: Sam Roberts <vieuxtech@gmail.com>
About path, address and port properties, these are not described though being also represented as augmented Error objects with added properties. And also, fix all property descriptions and add type annotations. PR-URL: #10986 Reviewed-By: James M Snell <jasnell@gmail.com> Reviewed-By: Sam Roberts <vieuxtech@gmail.com>
About path, address and port properties, these are not described though being also represented as augmented Error objects with added properties. And also, fix all property descriptions and add type annotations. PR-URL: #10986 Reviewed-By: James M Snell <jasnell@gmail.com> Reviewed-By: Sam Roberts <vieuxtech@gmail.com>
Checklist
Affected core subsystem(s)
doc
Description of change
In System Errors properties of Errors API,
error.path
,error.address
anderror.port
are not described although being also represented as augmented Error objects with added properties by the following code.Also,
error.errno
doesn't always return a number like the above examples.Please check the following code.
https://github.com/nodejs/node/blob/v6.x-staging/lib/util.js#L1024