Skip to content
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

Closed
wants to merge 4 commits into from

Conversation

jasnell
Copy link
Member

@jasnell jasnell commented Oct 28, 2017

  • Adds mechanism for transitioning internal UV and ErrnoException to internal/errors
  • Migrates os, tty, and dgram errors to internal/errors
Checklist
  • make -j4 test (UNIX), or vcbuild test (Windows) passes
  • tests and/or benchmarks are included
  • documentation is changed or added
  • commit message follows commit guidelines
Affected core subsystem(s)

src, os, dgram, tty

@nodejs-github-bot nodejs-github-bot added the lib / src Issues and PRs related to general changes in the lib or src directory. label Oct 28, 2017
@jasnell jasnell added errors Issues and PRs related to JavaScript errors originated in Node.js core. semver-major PRs that contain breaking changes and should be released in the next major version. dgram Issues and PRs related to the dgram subsystem / UDP. os Issues and PRs related to the os subsystem. tty Issues and PRs related to the tty subsystem. labels Oct 28, 2017
@jasnell
Copy link
Member Author

jasnell commented Oct 28, 2017

ping @nodejs/tsc

@jasnell
Copy link
Member Author

jasnell commented Oct 28, 2017

That wouldn't catch cases like new SystemError(null)

@targos
Copy link
Member

targos commented Oct 28, 2017

Can't that case be changed to pass undefined?

Object.defineProperty(this, kInfo, {
configurable: false,
enumerable: false,
value: context || {}
Copy link
Member

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

@maclover7
Copy link
Contributor

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?

@jasnell
Copy link
Member Author

jasnell commented Oct 29, 2017

@targos

Can't that case be changed to pass undefined

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.

@maclover7

Should any docs be added on the C++ side about the new way to throw errors

Yes, I'm planning to write up a more detailed guide on this once I'm through the initial conversion.


### error.info

`SystemError` instances may have an additional `info` property whose
Copy link
Member

@joyeecheung joyeecheung Oct 30, 2017

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?

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Copy link
Member Author

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

Copy link
Member

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..

Copy link
Member Author

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

Copy link
Member

@joyeecheung joyeecheung left a 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',
Copy link
Member

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?

Copy link
Member Author

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);
Copy link
Member

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");
Copy link
Member

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);
Copy link
Member

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.
@jasnell
Copy link
Member Author

jasnell commented Nov 2, 2017

@targos @joyeecheung ... updated, PTAL

Copy link
Member

@mhdawson mhdawson left a 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.

@mhdawson
Copy link
Member

mhdawson commented Nov 2, 2017

@jasnell
Copy link
Member Author

jasnell commented Nov 2, 2017

CI is good. failures are unrelated and known flakies

@jasnell
Copy link
Member Author

jasnell commented Nov 2, 2017

(getting this landed)

jasnell added a commit that referenced this pull request Nov 2, 2017
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]>
jasnell added a commit that referenced this pull request Nov 2, 2017
PR-URL: #16567
Reviewed-By: Joyee Cheung <[email protected]>
Reviewed-By: Michael Dawson <[email protected]>
jasnell added a commit that referenced this pull request Nov 2, 2017
PR-URL: #16567
Reviewed-By: Joyee Cheung <[email protected]>
Reviewed-By: Michael Dawson <[email protected]>
jasnell added a commit that referenced this pull request Nov 2, 2017
PR-URL: #16567
Reviewed-By: Joyee Cheung <[email protected]>
Reviewed-By: Michael Dawson <[email protected]>
@jasnell
Copy link
Member Author

jasnell commented Nov 2, 2017

Landed in c3dc0e0, 056b858, 3d9d849, and 9ad994b

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
dgram Issues and PRs related to the dgram subsystem / UDP. errors Issues and PRs related to JavaScript errors originated in Node.js core. lib / src Issues and PRs related to general changes in the lib or src directory. os Issues and PRs related to the os subsystem. semver-major PRs that contain breaking changes and should be released in the next major version. tty Issues and PRs related to the tty subsystem.
Projects
None yet
Development

Successfully merging this pull request may close these issues.

6 participants