errors: remove ERR_INVALID_ARRAY_LENGTH

[BridgeAR]

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), or vcbuild test (Windows) passes
• tests and/or benchmarks are included
• documentation is changed or added
• commit message follows commit guidelines

[joyeecheung]

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.

[BridgeAR]

@joyeecheung do you have a suggestion how to improve that?

[BridgeAR]

CI https://ci.nodejs.org/job/node-test-pull-request/14635/

[joyeecheung]

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

[BridgeAR]

You mean with a more detailed explanation of the error code? E.g., a reference to our errors.md?

[joyeecheung]

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

[joyeecheung]

On a second thought maybe metadata like error.api or error.anchor would be useful, although we still change our signature ids (the ones we use for markdown references) from time to time. Maybe it would be useful if we start to assign permanent ids to our APIs like what ecma262 does. (Just throwing ideas, not really related to this PR, sorry if it's totally off-topic)

[BridgeAR]

@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 errors.md subpar, especially when trying to give further context for the specific error. It is just to broad and not detailed enough. Otherwise I think it is a good idea. Maybe we can do that in a year or so after porting everything to our error codes and finalizing them.

[joyeecheung]

@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 Error.captureStackTrace would be less relevant).

[jasnell]

@joyeecheung

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

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.

[addaleax]

@BridgeAR Looks like this might need a rebase?

[BridgeAR]

Rebased.

CI before landing https://ci.nodejs.org/job/node-test-pull-request/14694/

[BridgeAR]

Landed in 186857f

[shobhitsharma]

Crashing quite a few packages like webpack

[mcollina]

@shobhitsharma on Node 11? Can you please make an example/link to an issue?