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

errors, process: port internal/process errors to internal/errors #11294

Closed
wants to merge 1 commit into from

Conversation

jasnell
Copy link
Member

@jasnell jasnell commented Feb 10, 2017

  • Assign codes to the handful of errors reported by internal/process/*.js
  • Include documentation for the new error codes
  • Improve error messages
  • Improve test coverage for process.nextTick

Ref: #11273

Semver-major because this updates specific error messages and converts errors over to use the new internal/errors.js mechanism.

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)

errors, process

@jasnell jasnell added the semver-major PRs that contain breaking changes and should be released in the next major version. label Feb 10, 2017
@nodejs-github-bot nodejs-github-bot added the errors Issues and PRs related to JavaScript errors originated in Node.js core. label Feb 10, 2017
@mscdex mscdex added the process Issues and PRs related to the process subsystem. label Feb 10, 2017
<a id="ERR_INVALID_ARG_TYPE"></a>
### ERR_INVALID_ARG_TYPE

The `'ERR_INVALID_ARG_TYPE'` error code is used generically to identify that
Copy link
Member

Choose a reason for hiding this comment

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

(Not sure which PR is the right place to ask, this one seems the oldest so I'll ask here)

Which one does the "type" here cover:

  • Primitive types (i.e. typeof types, doesn't differentiate Date and RegExp and stuff)
  • Builtin type tags(i.e. results of Object.prototype.toString.call(), differentiates Date and RegExp)
  • Class mismatch(i.e. instanceof types, differentiates Date and RegExp)

Copy link
Member

Choose a reason for hiding this comment

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

Also, some PRs use the typeof types as the expected type(e.g. "function"), some uses the class name/type tag(e.g. "Object"), we probably need to be a little bit consistent on this one.

Copy link
Member Author

Choose a reason for hiding this comment

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

This is not handled very consistently throughout the Node.js source. Sometimes the value itself is passed in, sometimes the typeof is used, etc. The goal here would be to start getting some consistency but it's hard to nail down exactly what that should be.

Copy link
Member

Choose a reason for hiding this comment

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

Got it, so we should focus on migrating the errors to use the new system with a reasonable code right now, and deal with message later, because after the migration it would be easier to change them anyway?

msg += `one of type ${expected.slice(0, len - 1).join(', ')}, or ` +
expected[len - 1];
} else {
msg += `type ${String(expected[0])}`;
Copy link
Member

Choose a reason for hiding this comment

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

String(..) seems unnecessary here?

Copy link
Member

Choose a reason for hiding this comment

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

+1. It's already cast on line 103

@jasnell
Copy link
Member Author

jasnell commented Feb 14, 2017

@nodejs/ctc ... as a semver major this needs some review and signoff

@jasnell
Copy link
Member Author

jasnell commented Feb 14, 2017

Copy link

@bougarfaoui bougarfaoui left a comment

Choose a reason for hiding this comment

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

@jasnell in the invalidArgType : what if the actual arg is null , the result will be . Received type object

@jasnell
Copy link
Member Author

jasnell commented Feb 14, 2017

Sigh, good point. I often forget that typeof null === 'object' which is really quite odd.

E('ERR_INVALID_CALLBACK', 'callback must be a function');
E('ERR_STDERR_CLOSE', 'process.stderr cannot be closed');
E('ERR_STDOUT_CLOSE', 'process.stdout cannot be closed');
E('ERR_UNK_STDIN_TYPE', 'Unknown stdin file type');
Copy link
Member

Choose a reason for hiding this comment

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

#11298 spells the full UNKNOWN, this should do the same (TBH I can not understand what UNK stands for at first glance...).

@jasnell jasnell force-pushed the internal-errors-1 branch 3 times, most recently from 7f1def6 to 86c7993 Compare February 16, 2017 20:24
@jasnell
Copy link
Member Author

jasnell commented Feb 16, 2017

@nodejs/ctc ... PTAL... I'd like to get this landed so we can start getting through the others that are starting to stack up

@jasnell
Copy link
Member Author

jasnell commented Mar 6, 2017

ping @evanlucas, @addaleax, @cjihrig and @mhdawson

@evanlucas
Copy link
Contributor

As I mentioned somewhere else (not sure where, there have been a bunch of these pull requests), I'm not thrilled with what the stack trace looks like after this change.

@jasnell
Copy link
Member Author

jasnell commented Mar 27, 2017

Which part are you unhappy with?

@evanlucas
Copy link
Contributor

$ ./node --expose-internals
> new errors.Error('ERR_ASSERTION', 'something')
{ Error[ERR_ASSERTION]: something
    at repl:1:1
    at ContextifyScript.Script.runInThisContext (vm.js:44:33)
    at REPLServer.defaultEval (repl.js:239:29)
    at bound (domain.js:301:14)
    at REPLServer.runBound [as eval] (domain.js:314:12)
    at REPLServer.onLine (repl.js:433:10)
    at emitOne (events.js:120:20)
    at REPLServer.emit (events.js:210:7)
    at REPLServer.Interface._onLine (readline.js:262:10)
    at REPLServer.Interface._line (readline.js:611:8) [Symbol(code)]: 'ERR_ASSERTION' }

I just find it a little harder to read Error[ERR_ASSERTION]: in particular. As opposed to Error:

@jasnell
Copy link
Member Author

jasnell commented Mar 27, 2017

Do you have an alternative suggestion? Displaying the error code in the output is a significant reason why this allows us to avoid treating changes in the error message as semver-major... That is, it gives the user a stable, non-changing key they can use to search for information on the specific error. Putting the [ERR_ASSERTION] on the other side of the : requires changing the actual error message.

@Trott
Copy link
Member

Trott commented Mar 28, 2017

As I mentioned somewhere else (not sure where, there have been a bunch of these pull requests), I'm not thrilled with what the stack trace looks like after this change.

I can't find it either, but I chimed in on that too. Error[ERR_ASSERTION] looks like an array value. At an absolute minimum, please put a space in there: Error [ERR_ASSERTION]:

If @evanlucas's output is accurate, the { and } surrounding the output should also be removed. They suggest the contents are an object or JSON.

@jasnell
Copy link
Member Author

jasnell commented Mar 28, 2017

The { and } is an artifact of util.inspect() rendering, not the internal errors piece.... for instance, do

> var m = new Error("test")
undefined
> m.code = 1
1
> m
{ Error: test
    at repl:1:9
    at ContextifyScript.Script.runInThisContext (vm.js:44:33)
    at REPLServer.defaultEval (repl.js:239:29)
    at bound (domain.js:301:14)
    at REPLServer.runBound [as eval] (domain.js:314:12)
    at REPLServer.onLine (repl.js:433:10)
    at emitOne (events.js:120:20)
    at REPLServer.emit (events.js:210:7)
    at REPLServer.Interface._onLine (readline.js:262:10)
    at REPLServer.Interface._line (readline.js:611:8) code: 1 }

I will open a PR that adds the space before the opening [

@gibfahn
Copy link
Member

gibfahn commented Mar 28, 2017

I will open a PR that adds the space before the opening [

PR: #12099

@jasnell
Copy link
Member Author

jasnell commented Apr 5, 2017

Ping @nodejs/ctc ... I'd like to get this landed. Before the other errors ones get landed.

@Trott
Copy link
Member

Trott commented Apr 5, 2017

@jasnell This needs at least one more CTC approval before landing. Maybe you can horse-trade with @trevnorris: You review his async-hooks PR that he's not getting enough reviews on and in return he reviews this.

I'm kidding. Or am I?

@jasnell
Copy link
Member Author

jasnell commented Apr 5, 2017

I'd review the async-hooks had I the time. It's a large pr. I can take a look next week. There are quite a few other prs pending on this one, all semver major, that I would like to get landed

var len = expected.length;
expected = expected.map((i) => String(i));
if (len > 1) {
msg += `one of type ${expected.slice(0, len - 1).join(', ')}, or ` +
Copy link
Contributor

Choose a reason for hiding this comment

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

Maybe break out the expected.slice().join() into a variable? It is getting a little hard to read imo.

} else {
msg += `of type ${String(expected)}`;
}
if (arguments.length >= 3) {
Copy link
Contributor

Choose a reason for hiding this comment

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

With only the first three arguments being used, maybe make this if (arguments.length === 3) {?

Feel free to disregard

@jasnell
Copy link
Member Author

jasnell commented Apr 19, 2017

@evanlucas ... do you still object to this?

@evanlucas
Copy link
Contributor

@jasnell my review was not an objection. I think I'm onboard with this now.

@jasnell
Copy link
Member Author

jasnell commented Apr 19, 2017

Awesome, ok. Can I ask you to switch the "requested changes" to an approval or LGTM so I can get this landed. As a semver-major I need two CTC signoffs :-)

* Assign codes to the handful of errors reported by
  internal/process/*.js
* Include documentation for the new error codes
* Improve error messages
* Improve test coverage for process.nextTick

Ref: nodejs#11273
@jasnell
Copy link
Member Author

jasnell commented Apr 20, 2017

@jasnell
Copy link
Member Author

jasnell commented Apr 20, 2017

CI failures are unrelated. Failures in CITGM are not specific to this PR.

jasnell added a commit that referenced this pull request Apr 20, 2017
* Assign codes to the handful of errors reported by
  internal/process/*.js
* Include documentation for the new error codes
* Improve error messages
* Improve test coverage for process.nextTick

PR-URL: #11294
Ref: #11273
Reviewed-By: Michaël Zasso <targos@protonmail.com>
Reviewed-By: Joyee Cheung <joyeec9h3@gmail.com>
Reviewed-By: Evan Lucas <evanlucas@me.com>
@jasnell
Copy link
Member Author

jasnell commented Apr 20, 2017

Landed in e75bc87

@jasnell jasnell closed this Apr 20, 2017
@Trott Trott removed the ctc-review label Apr 24, 2017
@jasnell jasnell mentioned this pull request May 11, 2017
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
errors Issues and PRs related to JavaScript errors originated in Node.js core. process Issues and PRs related to the process subsystem. semver-major PRs that contain breaking changes and should be released in the next major version.
Projects
None yet
Development

Successfully merging this pull request may close these issues.

9 participants