errors: move error codes into separate module

[starkwang]

Move error codes into a new separate module internal/error_codes. And the guides/using-internal-errors.md are also changed.

This PR only separate the error codes in internal/errors.js. I think the rest of error codes in ./lib should wait for some future PRs.

Ref: #14216, #11273

Checklist

• make -j4 test (UNIX), or vcbuild test (Windows) passes
• documentation is changed or added
• commit message follows commit guidelines

Affected core subsystem(s)

errors

[Trott]

Would it be better to create an internal/errors directory, move internal/errors.js to internal/errors/index.js and put the codes in internal/errors/codes.js?

[vsemozhetbyt]

Linting nit: missing semicolon.

[starkwang]

fixed

[starkwang]

@Trott I tried to create an internal/errors directory (with index.js and codes.js in it), but found the module system failed to load internal/errors/index.js whenrequire('internal/errors')

Error [ERR_UNKNOWN_BUILTIN_MODULE]: No such built-in module: internal/errors

[Trott]

@starkwang Ah! It looks like we may have run into a similar issue with internal/process and we just left lib/internal/process.js and put other files in lib/internal/process/. So maybe you can do that. (In other words, leave internal/errors.js where it is now but create internal/errors directory and put codes.js in there.)

[starkwang]

Pushed commit to address comments.

[Trott]

Needs one small doc change but otherwise looks good to me if the CI is green.

[Trott]

The path here needs to be updated to reflect the new location of the file.

[starkwang]

Doc fixed.

[Trott]

/cc @jasnell

[Trott]

LGTM if CI is green.

[joyeecheung]

Ping @starkwang, this needs a rebase.

[jasnell]

FWIW, I am -1 on this approach as it currently stands. There is no reason to move the codes to a separate file and doing so now would unnecessarily disrupt the current ongoing migration process. If we want to expose the codes as constants, then those can be dropped off the existing internal/errors module.exports target.

[refack]

FWIW, I am -1 on this approach as it currently stands. There is no reason to move the codes to a separate file and doing so now would unnecessarily disrupt the current ongoing migration process. If we want to expose the codes as constants, then those can be dropped off the existing internal/errors module.exports target.

@jasnell didn't you suggest moving them to a json file?
IMHO if they are moving out they should go with their messages, and maybe after all migrations are done.

[jasnell]

Eventually, yes, but these are fairly difficult to manage as it is. Once the migration is done we can revisit. I have a few things in mind already also...