-
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
src, os, dgram, tty: migrate to internal errors #16567
Conversation
ping @nodejs/tsc |
That wouldn't catch cases like |
Can't that case be changed to pass |
lib/internal/errors.js
Outdated
Object.defineProperty(this, kInfo, { | ||
configurable: false, | ||
enumerable: false, | ||
value: context || {} |
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.
context is guaranteed to be truthy here
This is really great! Should any docs be added on the C++ side about the new way to throw errors... maybe in the style guide? |
potentially. Let's save that particular change for later tho. Once I get through converting all of the native level code to use this I will verify that we can safely make that assumption.
Yes, I'm planning to write up a more detailed guide on this once I'm through the initial conversion. |
6350e83
to
4a8cbd3
Compare
|
||
### error.info | ||
|
||
`SystemError` instances may have an additional `info` property whose |
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.
Come to think of it, I think a more popular pattern in the userland is using the err.data
property (correct me if I am wrong), I remember seeing some logging services/tools collect that automatically in addition to err.code
...I remember there is another PR for crypto that use info
. Is there a reason that we pick info
instead of data
?
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.
A quick search in our own code base shows that eslint is using error.data
: https://github.com/nodejs/node/blob/master/tools/eslint/lib/config/config-validator.js#L92 and https://github.com/nodejs/node/blob/master/tools/eslint/lib/config/config-validator.js#L179
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've seen both: https://www.npmjs.com/package/verror uses *.info
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.
On a side note: would be easier to read if we have a syntax for documenting optional properties..
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 agree, definitely something worth working on
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.
Changes LGTM, left a few suggestions.
const ctx = {}; | ||
const ret = self._handle.bufferSize(size, buffer, ctx); | ||
if (ret === undefined) { | ||
throw new errors.Error('ERR_SOCKET_BUFFER_SIZE', |
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 this for avoiding changing the error type? Maybe a comment because this looks a bit odd at first?
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.
Yes, I really dislike how this was done, but I want to save it for a different PR to change it.
lib/os.js
Outdated
const ctx = {}; | ||
const ret = fn(...args, ctx); | ||
if (ret === undefined) { | ||
throw new errors.SystemError(ctx); |
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.
Maybe name this function and do a captureStackTrace()
?
src/node_os.cc
Outdated
@@ -351,7 +356,8 @@ static void GetUserInfo(const FunctionCallbackInfo<Value>& args) { | |||
const int err = uv_os_get_passwd(&pwd); | |||
|
|||
if (err) { | |||
return env->ThrowUVException(err, "uv_os_get_passwd"); | |||
env->CollectUVExceptionInfo(args[1], err, "uv_os_get_passwd"); |
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.
For clarity, maybe use args[args.Length() - 1]
? Also we should probably CHECK_EQ(args.Length(), n)
or CHECK_GE(args.Length(), n)
(not sure if these are used in userland)
dest: Buffer.from('b') | ||
}; | ||
const err = new errors.SystemError(ctx); | ||
assert.strictEqual(err.info, ctx); |
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 one is not legacy, right? Should we move the comment below this?
Preparing for the migration of existing UVException and ErrnoExceptions from the native layer, add new `errors.SystemError` to internal/errors and new `env->CollectExceptionInfo()` / `env->CollectUVExceptionInfo()` methods.
4a8cbd3
to
ee9e7a6
Compare
@targos @joyeecheung ... updated, 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.
LGTM as long as CI is green.
CI is good. failures are unrelated and known flakies |
(getting this landed) |
Preparing for the migration of existing UVException and ErrnoExceptions from the native layer, add new `errors.SystemError` to internal/errors and new `env->CollectExceptionInfo()` / `env->CollectUVExceptionInfo()` methods. PR-URL: #16567 Reviewed-By: Joyee Cheung <[email protected]> Reviewed-By: Michael Dawson <[email protected]>
PR-URL: #16567 Reviewed-By: Joyee Cheung <[email protected]> Reviewed-By: Michael Dawson <[email protected]>
PR-URL: #16567 Reviewed-By: Joyee Cheung <[email protected]> Reviewed-By: Michael Dawson <[email protected]>
PR-URL: #16567 Reviewed-By: Joyee Cheung <[email protected]> Reviewed-By: Michael Dawson <[email protected]>
Checklist
make -j4 test
(UNIX), orvcbuild test
(Windows) passesAffected core subsystem(s)
src, os, dgram, tty