-
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
errors: improve error types #13857
errors: improve error types #13857
Conversation
Marking as semver-major due to error message change(s). |
lib/internal/errors.js
Outdated
E('ERR_TRANSFORM_WITH_LENGTH_0', | ||
'Calling transform done when ws.length != 0'); | ||
E('ERR_HTTP_TRAILER_INVALID', | ||
'Trailers are invalid with this transfer encoding'); | ||
E('ERR_UNKNOWN_BUILTIN_MODULE', (id) => `No such built-in module: ${id}`); |
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.
Instead of removing this, perhaps it should instead be used to replace the manual/old Error
creation in lib/internal/bootstrap_node.js ?
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 didn't do that because of the comment right above that error:
// Model the error off the internal/errors.js model, but
// do not use that module given that it could actually be
// the one causing the error if there's a bug in Node.js
doc/api/errors.md
Outdated
Used when a callback is called more than once. | ||
|
||
<a id="ERR_ASSERTION"></a> | ||
### ERR_ASSERTION |
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.
These should be in alphabetical order.
doc/api/errors.md
Outdated
<a id="ERR_CPU_USAGE"></a> | ||
### ERR_CPU_USAGE | ||
|
||
Used when the native call from process.cpuUsage can't be processed properly. |
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.
nit: please avoid the use of contractions... s/can't/cannot
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.
nit: process.cpuUsage is code and should probably be process.cpuUsage
doc/api/errors.md
Outdated
### ERR_HTTP_HEADERS_SENT | ||
|
||
Used in case the headers were already sent and another attempt is made to add | ||
more headers. |
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.
Used when headers have already been sent and another ...
doc/api/errors.md
Outdated
<a id="ERR_INVALID_CHAR"></a> | ||
### ERR_INVALID_CHAR | ||
|
||
Used in e.g. http if invalid characters are detected in headers. |
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.
Used when invalid characters are detected in headers.
doc/api/errors.md
Outdated
<a id="ERR_HTTP_INVALID_STATUS_CODE"></a> | ||
### ERR_HTTP_INVALID_STATUS_CODE | ||
|
||
Used for nonexisting status codes. |
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.
Not quite. non-existing
would be non-registered. The code actually allows using valid but not-registered status codes (e.g. I could send 999
). The error is thrown when the status code is < 100
or > 999
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 am aware that the validation is less strict but personally I would keep the description like that as it feels more intuitive to me. With the range I would wonder why that range was chosen. As far as I know the current bounds were chosen to be "somewhat" near the regular status codes.
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 do see your point about non-existing as well though.
doc/api/errors.md
Outdated
<a id="ERR_INVALID_ARRAY_LENGTH"></a> | ||
### ERR_INVALID_ARRAY_LENGTH | ||
|
||
Used in case a array is not of the expected length or in a valid range. |
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.
Used when an Array is not ...
doc/api/errors.md
Outdated
<a id="ERR_INVALID_FD"></a> | ||
### ERR_INVALID_FD | ||
|
||
Used in case a FD entry is not valid (i.e. negative). |
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.
Used when a file descriptor ('fd') is not valid.
doc/api/errors.md
Outdated
<a id="ERR_PARSE_HISTORY_DATA"></a> | ||
### ERR_PARSE_HISTORY_DATA | ||
|
||
Used in the `repl` if you use the old history file and an error occurred while |
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.
Please avoid the use of informal personal pronouns like you
in the docs
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.
if the old history file is used
doc/api/errors.md
Outdated
### ERR_HTTP_TRAILER_INVALID | ||
|
||
Used when the `Trailer` header is set even though the encoding does not support | ||
that. |
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 is misleading. It's not the encoding
that matters, it is the transfer encoding ...
doc/api/errors.md
Outdated
<a id="ERR_V8BREAKITERATOR"></a> | ||
### ERR_V8BREAKITERATOR | ||
|
||
Used if the full ICU data is not installed. |
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.
Used when the V8 BreakIterator API is used but the full ICU data set is not installed.
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.
Thank you for working on this. Left some comments.
doc/api/errors.md
Outdated
<a id="ERR_MULTIPLE_CALLBACK"></a> | ||
### ERR_MULTIPLE_CALLBACK | ||
|
||
Used when a callback is called more than once. |
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.
nit: I'm not sure this is indicative enough for people new to node.
doc/api/errors.md
Outdated
<a id="ERR_TRANSFORM_ALREADY_TRANSFORMING"></a> | ||
### ERR_TRANSFORM_ALREADY_TRANSFORMING | ||
|
||
Used when stream transform done is called even though it is still in process. |
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 sure this is indicative enough.
Nice work, I think some examples for the errors would be really nice but I'm fine with landing it (after the requested fixes) without them and iterating. |
7726155
to
f0a6b15
Compare
Note: I explicitly do not document |
85920fb
to
885a725
Compare
885a725
to
33e1f36
Compare
Comments addressed. @jasnell would you be so kind and just drop a comment about my suggestions in the PR description? I could open a separate issue for these if preferred. |
throw err; | ||
} | ||
if (err && err.message !== 'Channel closed') { | ||
throw err; |
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.
Note: the thrown error should never have that error code ECONNREFUSED
as far as I can see.
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.
#8950
I'll run a stress test
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.
Generally LGTM with one nit
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.
LGTM. Thanks for all the hard work to refine/improve the errors.
1) Add missing lazy assert call 2) Remove obsolete error type 3) Name undocumented error type more appropriate 4) Consolidate error type style (rely on util.format instead of using a function) 5) Uppercase the first letter from error messages 6) Improve some internal error parameters
d7a25e3
to
eff06a3
Compare
Nit addressed and rebased |
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.
Need to test
test/parallel/test-child-process-fork-regr-gh-2847.js
throw err; | ||
} | ||
if (err && err.message !== 'Channel closed') { | ||
throw err; |
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.
#8950
I'll run a stress test
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.
Stress passed
Pre land CI: https://ci.nodejs.org/job/node-test-commit/10778/ |
After 4 hours of stalled build on the Raspberry Pi devices, I canceled the CI run on that platform. The devices need attention, I'm afraid. This will either have to land without a CI run on the Raspberry Pi's (which I think is probably OK) or else wait for the CI builds to start working again (shouldn't be too long before that happens, Rod mentioned in IRC he was looking at it). |
CI on arm: https://ci.nodejs.org/job/node-test-commit-arm-fanned/9641/ Other failures appear to be unrelated / flaky tests. |
Given this: nodejs/build#774 (comment) I think its probably ok to land without arm results. |
PR-URL: #13857 Reviewed-By: Refael Ackermann <[email protected]> Reviewed-By: James M Snell <[email protected]> Reviewed-By: Colin Ihrig <[email protected]> Reviewed-By: Michael Dawson <[email protected]>
1) Add missing lazy assert call 2) Remove obsolete error type 3) Name undocumented error type more appropriate 4) Consolidate error type style (rely on util.format instead of using a function) 5) Uppercase the first letter from error messages 6) Improve some internal error parameters PR-URL: #13857 Reviewed-By: Refael Ackermann <[email protected]> Reviewed-By: James M Snell <[email protected]> Reviewed-By: Colin Ihrig <[email protected]> Reviewed-By: Michael Dawson <[email protected]>
PR-URL: #13857 Reviewed-By: Refael Ackermann <[email protected]> Reviewed-By: James M Snell <[email protected]> Reviewed-By: Colin Ihrig <[email protected]> Reviewed-By: Michael Dawson <[email protected]>
PR-URL: #13857 Reviewed-By: Refael Ackermann <[email protected]> Reviewed-By: James M Snell <[email protected]> Reviewed-By: Colin Ihrig <[email protected]> Reviewed-By: Michael Dawson <[email protected]>
PR-URL: #13857 Reviewed-By: Refael Ackermann <[email protected]> Reviewed-By: James M Snell <[email protected]> Reviewed-By: Colin Ihrig <[email protected]> Reviewed-By: Michael Dawson <[email protected]>
Landed in 8ca9338 ... 2fa2a60, thank you! 🎉 Post-merge (partial) CI: https://ci.nodejs.org/job/node-test-commit-linuxone/6913/ |
PR-URL: nodejs#13857 Reviewed-By: Refael Ackermann <[email protected]> Reviewed-By: James M Snell <[email protected]> Reviewed-By: Colin Ihrig <[email protected]> Reviewed-By: Michael Dawson <[email protected]>
Backport-PR-URL: #22380 PR-URL: #13857 Reviewed-By: Refael Ackermann <[email protected]> Reviewed-By: James M Snell <[email protected]> Reviewed-By: Colin Ihrig <[email protected]> Reviewed-By: Michael Dawson <[email protected]>
While working on the internal errors a bit more I realized that there are multiple error types not yet documented and some have minor shortcomings. Here I mainly just document the missing ones. All changes are summarized in the commit messages.
I feel the change to always rely on
util.format
for the arguments passed to error types might actually be the wrong way and instead we should always use a function. The latter would likely be a tad faster and we could also validate the args in that case. Relying on util.format is nicer to read though and shorter.Besides that I want to kick of a short discussion about the error types in general. I know I'm late to the party but maybe my two cents are still worth the effort:
For me the error codes are most useful when a bit more abstract and if they cover a range of more specific errors and are not bound to exactly one error (with exceptions) (i.e. a single bound error type with a optional lower and upper bound instead of a individual bounds error each time).
That way the user can handle some generic ones in his code if wanted and necessary. I think handling lots of very specific ones is often not doable or as useful.
So if there's still a possibility to do this, I would say let's try to always find more generic approaches and go so far to consolidate a few already existing error codes. As some were not yet documented, it's easier with them but all others would have to be changed as semver major and I'm not sure if it's worth the effort in that case.
Here's my view on what could still be improved:
ERR_INVALID_FD
not yet documented and this could easily be a more generic oneERR_INVALID_CALLBACK
could be replaced with ERR_INVALID_ARG_TYPE. That essentially does the same, just not as specific to callbacks. If you want to outline the callbacks, it should stay as it is.ERR_INVALID_REPL_EVAL_CONFIG
could be generic with something similar to: "Receive two types that may not be set at the same time."ERR_STDERR_CLOSE
andERR_STDOUT_CLOSE
could be consolidated toERR_STD_CLOSE
ERR_UNKNOWN_STREAM_TYPE
andERR_STDIN_STREAM_TYPE
could be consolidated toERR_UNKNOWN_UV_TYPE
ERR_SOCKET_BAD_PORT
I think it would be better to use a generic range / bound error insteadERR_SOCKET_BAD_TYPE
could be converted to a more generic approach with predefined allowed entries.Besides that it would recommend to try to limit adding new error codes to the bare minimum.
Summoning @jasnell
If all or some of my suggestions find acclaim, I'd open another PR to address these points.
Checklist
make -j4 test
(UNIX), orvcbuild test
(Windows) passesAffected core subsystem(s)
errors,dgram,process,util,v8,http