-
Notifications
You must be signed in to change notification settings - Fork 28.8k
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: remove ERR_INVALID_ARRAY_LENGTH #20484
Conversation
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.
FWIW, I always feel that the error message mentioning only the argument name seems a bit confusing. Not that ERR_INVALID_ARRAY_LENGTH
is any better in this regard though.
@joyeecheung do you have a suggestion how to improve that? |
@BridgeAR It would be really helpful if there is something that can generate URLs (on error codes and related API signatures) based on the error. That something does not have to be in core though. |
You mean with a more detailed explanation of the error code? E.g., a reference to our |
@BridgeAR yeah, but probably it would be better pointing to the HTML for the same release line since signatures can change. It's not really feasible to put too much information in the error message so we might as well show users URLs (like, modules that show users stackoverflow URLs for mistakes and errors seem to be quite popular in the python world). Although that thing probably can just be an npm module. |
On a second thought maybe metadata like |
@joyeecheung adding a extra property that contains the url to our current release line documentation should be possible. Honestly speaking, I do not think it is the right time to do that though. Often, I find the current documentation in |
@BridgeAR Hm, to be honest I don't think hard-coding URLs as metadata is a good idea, since URLs can change. Adding permanent API ids as metadata and then generating URLs with it could be, and I think it would help user-land REPLs provide something better for the users, referencing our docs or not. Probably would also help users googling answers on stackoverflow/github issues since there is something you know you can search for meaningful results. There would also be less amount of guesswork when debugging an error without proper stack traces (and the usage of the non-standard |
And based on the Node.js version. It should point to the documentation for that error message for the particular Node.js version that was used given that obsolete codes are removed. |
@BridgeAR Looks like this might need a rebase? |
This error code is obsolete, since the error message from ERR_OUT_OF_RANGE is more precise. It was only used a single time, so I went ahead and replced this.
ad16834
to
a77b752
Compare
Rebased. CI before landing https://ci.nodejs.org/job/node-test-pull-request/14694/ |
This error code is obsolete, since the error message from ERR_OUT_OF_RANGE is more precise. It was only used a single time, so I went ahead and replced this. PR-URL: nodejs#20484 Reviewed-By: Joyee Cheung <joyeec9h3@gmail.com> Reviewed-By: James M Snell <jasnell@gmail.com> Reviewed-By: Trivikram Kamat <trivikr.dev@gmail.com>
Landed in 186857f |
Crashing quite a few packages like |
@shobhitsharma on Node 11? Can you please make an example/link to an issue? |
This error code is obsolete, since the error message from
ERR_OUT_OF_RANGE is more precise. It was only used a single time,
so I went ahead and replced this.
#20483 should land first.
Checklist
make -j4 test
(UNIX), orvcbuild test
(Windows) passes