Skip to content

Tracking Issue: Migrate errors to internal/errors.js #11273

Description

@jasnell

Now that #11220 has landed, we need to begin the process of migrating errors in the */lib.js source over to use it. A basic guide is provided here.

Note that moving existing errors over to this mechanism should, in general, be considered semver-major.

Please use the following list to track which files have been migrated over to using the new errors and provide a link back to this issue in the relevant PRs

stream related (blocked)

@refack: removed GFC label and commented out sentence in description + split off stream stuff
@BridgeAR: updated the list

Activity

  1. added
    errorsIssues and PRs related to JavaScript errors originating in Node.js core.
    on Feb 9, 2017
  2. fl0w commented on Feb 10, 2017

    @fl0w

    Am I wrong in thinking this could be a "good first contribution"? Would love to give it a try in that case.
    Also, I'm assuming */lib.js is a typo for lib/*.js?

  3. joyeecheung commented on Feb 10, 2017

    @joyeecheung
    Member

    I think this could be a good first contribution in general, though some of the errors could be more complicated(the ones that are more frequently getting parsed in userland).

    Also, I'm assuming /lib.js is a typo for lib/.js?

    Probably lib/**/*.js :)

  4. joyeecheung commented on Feb 10, 2017

    @joyeecheung
    Member

    @jasnell I've added links to those files, hope I am doing this right..

  5. jasnell commented on Feb 10, 2017

    @jasnell
    MemberAuthor

    @fl0w ... yes, this can be a good first contribution. Please use my PR #11294 as a model. New error codes are added to internal/errors.js. Please reuse existing codes as possible. For instance, my PR #11294 introduces the ERR_INVALID_ARG_TYPE error code. If you're going through and making changes before #11294 lands, and you need ERR_INVALID_ARG_TYPE, duplicate it from #11294 as a separate commit in your PR. Then, if #11294 lands first, you can rebase and drop that commit, but if your PR lands first, then I can rebase and drop it from mine, etc. (hopefully that makes sense).

    Also please make sure that descriptions for the error codes are added to docs/api/errors.md the way I've illustrated in #11294.

    Really appreciate your willingness to jump in! Let me know if you have any questions or issues!

  6. seppevs commented on Feb 10, 2017

    @seppevs
    Contributor

    @jasnell: can we modify the error messages of existing errors to more generic and reusable error messages? Or should the error message be completely backwards compatible?

  7. jasnell commented on Feb 10, 2017

    @jasnell
    MemberAuthor

    Modifying the error message is certainly possible. The biggest thing is to avoid duplicating error codes so make sure you check the other PRs for codes that may be reusable.

  8. joyeecheung commented on Feb 11, 2017

    @joyeecheung
    Member

    Do we need to launch CITGM for all these semver-major PRs? cc @nodejs/build

  9. jasnell commented on Feb 11, 2017

    @jasnell
    MemberAuthor

    We should, yes.

  10. 124 remaining items

  11. added a commit that references this issue on Oct 15, 2017
  12. BridgeAR commented on Dec 16, 2017

    @BridgeAR
    Member

    I am closing this as outdated. All regular JS errors got migrated but might need some more polishing here and there. There are a couple c++ errors that should be migrated but this was never tracked here.

  13. joyeecheung commented on Dec 16, 2017

    @joyeecheung
    Member

    @BridgeAR There seems to be a few new old-style errors added in JS since this PR opened, searching new Error\(.+\) yields 23 results in the current master. We should probably open a new issue for that.

  14. joyeecheung commented on Mar 31, 2019

    @joyeecheung
    Member

    I believe this issue is mostly done now except the punycode ones. I opened #27023 for that, so I am going to close this. Feel free to reopen if anyone thinks otherwise.

  15. joyeecheung commented on Mar 31, 2019

    @joyeecheung
    Member

    Oops, did not realize it was closed. Sorry about the noise.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    errorsIssues and PRs related to JavaScript errors originating in Node.js core.metaIssues and PRs related to the general management of the project.

    Type

    No type

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions