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

lib: combine similar error codes #17648

Closed
wants to merge 1 commit into from

Conversation

starkwang
Copy link
Contributor

@starkwang starkwang commented Dec 13, 2017

There two similar error codes in lib: ERR_VALUE_OUT_OF_RANGE and ERR_OUT_OF_RANGE. This change is to:

  • reduce them into ERR_VALUE_OUT_OF_RANGE
  • make some error messages more detailed

Fix: #17603

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)

@nodejs-github-bot nodejs-github-bot added the lib / src Issues and PRs related to general changes in the lib or src directory. label Dec 13, 2017
@cjihrig
Copy link
Contributor

cjihrig commented Dec 13, 2017

I'm not for or against this, but it definitely defeats the purpose of the error code movement. Theoretically, the idea is that the error message strings can change freely but the codes themselves will never change.

@starkwang
Copy link
Contributor Author

Theoretically, the idea is that the error message strings can change freely but the codes themselves will never change.

@cjihrig Agreed. But I think the reduction of error codes is also important.

@maclover7 maclover7 added the semver-major PRs that contain breaking changes and should be released in the next major version. label Dec 13, 2017
Copy link
Member

@TimothyGu TimothyGu left a comment

Choose a reason for hiding this comment

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

Not too happy about this either, but more "not happy about the fact that we have to do this" than "not happy about the fact that we are doing this".

@BridgeAR
Copy link
Member

@cjihrig as far as I see it there is still going to be some work about that but it is going to reduce a lot over time.

@BridgeAR BridgeAR added the author ready PRs that have at least one approval, no pending requests for changes, and a CI started. label Dec 13, 2017
@BridgeAR
Copy link
Member

I mark this as ready even though it should probably wait the full 48 hours and how do we handle error codes at the moment? Do we still require two TSC votes on it? I remember that we spoke about loosening that in Vancouver but I am not sure what happened afterwards about it.

@jasnell
Copy link
Member

jasnell commented Dec 14, 2017

changing error codes is definitely server-Major and would require two TSC votes

@targos
Copy link
Member

targos commented Dec 14, 2017

I haven't reviewed the code but I'm +1 on the change

Copy link
Contributor

@maclover7 maclover7 left a comment

Choose a reason for hiding this comment

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

+1, good to take care of these types of changes while new error codes are still being introduced, hopefully won't be too much ecosystem breakage.

@maclover7
Copy link
Contributor

Should this breaking change be documented somewhere, maybe the ERR_OUT_OF_RANGE should remain in doc/api/errors.md with a note saying it has been replaced, for those still expecting it?

Copy link
Member

@apapirovski apapirovski left a comment

Choose a reason for hiding this comment

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

Can we use ERR_OUT_OF_RANGE instead going forward? There are 4 places currently that have ERR_VALUE_OUT_OF_RANGE compared to like 35 uses of the former.

Also, while at it, could you update to use RangeError everywhere instead of TypeError?

Thanks!

@starkwang
Copy link
Contributor Author

Can we use ERR_OUT_OF_RANGE instead going forward? There are 4 places currently that have ERR_VALUE_OUT_OF_RANGE compared to like 35 uses of the former.

@apapirovski Actually there are 5 places using ERR_VALUE_OUT_OF_RANGE and 9 places using ERR_OUT_OF_RANGE in lib

We use ERR_VALUE_OUT_OF_RANGE instead of the other because the error message of ERR_VALUE_OUT_OF_RANGE is more detailed. It gives the expected range and received value in error message. In contrast, the ERR_OUT_OF_RANGE only gives the value name.

Also, while at it, could you update to use RangeError everywhere instead of TypeError?

Yes, I will fix it : )

@apapirovski
Copy link
Member

apapirovski commented Dec 14, 2017

Actually there are 5 places using ERR_VALUE_OUT_OF_RANGE and 9 places using ERR_OUT_OF_RANGE in lib

There are 5 total instances of ERR_VALUE_OUT_OF_RANGE, that is 5 total errors that throw that code. There are 37 instances of ERR_OUT_OF_RANGE, 28 in lib/fs.js alone.

We use ERR_VALUE_OUT_OF_RANGE instead of the other because the error message of ERR_VALUE_OUT_OF_RANGE is more detailed. It gives the expected range and received value in error message. In contrast, the ERR_OUT_OF_RANGE only gives the value name.

The error message can be modified on ERR_OUT_OF_RANGE instead. That's the whole point of error codes.

@jasnell
Copy link
Member

jasnell commented Dec 14, 2017

I would rather use the ERR_OUT_OF_RANGE code also.

@addaleax
Copy link
Member

addaleax commented Dec 14, 2017

I think I’d prefer ERR_VALUE_OUT_OF_RANGE, just because it seems not too unlikely that at some point we might want to have something like ERR_INDEX_OUT_OF_RANGE as well? And even if not, the ERR_VALUE_OUT_OF_RANGE doesn’t have that value/index ambiguity in its name.

Edit: Okay, in that case we might also want to call it “out of bounds”, not “out of range”… I still feel like that’s something that might be easy to mix up for non-native speakers of English

@apapirovski
Copy link
Member

apapirovski commented Dec 14, 2017

For ERR_INDEX_OUT_OF_RANGE, I would think we would want to just use ERR_OUT_OF_RANGE for both and just have the message say index is out of range or something. I'm not sure I see a benefit to using a unique error code for it.

The benefit of changing ERR_VALUE_OUT_OF_RANGE > ERR_OUT_OF_RANGE is:

  1. less churn
  2. while this remain semver-major, less people are potentially affected by this change.

IMO the introduction of ERR_VALUE_OUT_OF_RANGE was an oversight anyway. We had ERR_OUT_OF_RANGE much longer.

@starkwang
Copy link
Contributor Author

Pushed commit to address comment. Changes are:

  • use ERR_OUT_OF_RANGE
  • use RangeError everywhere
  • document in doc/api/errors.md that ERR_VALUE_OUT_OF_RANGE is longer used and replaced by ERR_OUT_OF_RANGE.

@apapirovski
Copy link
Member

apapirovski commented Dec 14, 2017

Also, this could potentially land in two separate commits:

  1. Improve error message for ERR_OUT_OF_RANGE (this can then be backported)
  2. Change ERR_VALUE_OUT_OF_RANGE > ERR_OUT_OF_RANGE (semver-major)

I don't know if it's worth it but something to consider?

@@ -1568,7 +1568,7 @@ entry types were found.
<a id="ERR_VALUE_OUT_OF_RANGE"></a>
### ERR_VALUE_OUT_OF_RANGE

A given value is out of the accepted range.
**Discarded**. It has been replaced by `ERR_OUT_OF_RANGE`.
Copy link
Member

Choose a reason for hiding this comment

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

I wouldn't say discarded. Maybe just keep its description and say something like "Superseded by ERR_OUT_OF_RANGE." Maybe this should also somehow mention the Node.js version? I don't know... we don't have a policy around this right now, do we?

Copy link
Contributor

Choose a reason for hiding this comment

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

Should this go into the deprecations?

@Fishrock123
Copy link
Contributor

I'm not for or against this, but it definitely defeats the purpose of the error code movement. Theoretically, the idea is that the error message strings can change freely but the codes themselves will never change.

I'm not sure about that. The purpose of the movement was to allow the messages to be semver-patch. Actually then changing the code-meaning of the error is still semver-major just as normal.

@apapirovski
Copy link
Member

Actually then changing the code-meaning of the error

I don't think that's happening in this PR, is it? The meaning is still exactly the same, just with more insight.

@starkwang
Copy link
Contributor Author

Rebased to resolve conflicts and fixed some broken tests.

@BridgeAR
Copy link
Member

This needs another rebase.

@starkwang
Copy link
Contributor Author

Rebased to resolve conflicts.

@BridgeAR
Copy link
Member

There two similar error codes in lib: "ERR_VALUE_OUT_OF_RANGE"
and "ERR_OUT_OF_RANGE". This change is to reduce them into
"ERR_VALUE_OUT_OF_RANGE"

Fixes: nodejs#17603
@starkwang
Copy link
Contributor Author

Rebased again to resolve conflicts.
Is there anyone can open a new CI and land this PR?

@joyeecheung
Copy link
Member

starkwang added a commit that referenced this pull request Dec 24, 2017
There two similar error codes in lib: "ERR_VALUE_OUT_OF_RANGE"
and "ERR_OUT_OF_RANGE". This change is to reduce them into
"ERR_VALUE_OUT_OF_RANGE"

Fixes: #17603

PR-URL: #17648
Fixes: #17603
Reviewed-By: Timothy Gu <timothygu99@gmail.com>
Reviewed-By: James M Snell <jasnell@gmail.com>
Reviewed-By: Ruben Bridgewater <ruben@bridgewater.de>
Reviewed-By: Rich Trott <rtrott@gmail.com>
Reviewed-By: Jon Moss <me@jonathanmoss.me>
Reviewed-By: Anatoli Papirovski <apapirovski@mac.com>
Reviewed-By: Anna Henningsen <anna@addaleax.net>
@starkwang
Copy link
Contributor Author

Landed in d022cb1

@starkwang starkwang closed this Dec 24, 2017
@addaleax addaleax removed the author ready PRs that have at least one approval, no pending requests for changes, and a CI started. label Dec 29, 2017
ChALkeR added a commit to ChALkeR/io.js that referenced this pull request Aug 6, 2018
This removes two unused error codes:
 * ERR_STREAM_READ_NOT_IMPLEMENTED, removed in c979488 (PR nodejs#18813).
 * ERR_VALUE_OUT_OF_RANGE, removed in d022cb1 (PR nodejs#17648).

PR-URL: nodejs#21491
Reviewed-By: Michaël Zasso <targos@protonmail.com>
Reviewed-By: Rich Trott <rtrott@gmail.com>
Reviewed-By: James M Snell <jasnell@gmail.com>
Reviewed-By: Michael Dawson <michael_dawson@ca.ibm.com>
Reviewed-By: Colin Ihrig <cjihrig@gmail.com>
Reviewed-By: Joyee Cheung <joyeec9h3@gmail.com>
Reviewed-By: Anatoli Papirovski <apapirovski@mac.com>
targos pushed a commit that referenced this pull request Aug 6, 2018
This removes two unused error codes:
 * ERR_STREAM_READ_NOT_IMPLEMENTED, removed in c979488 (PR #18813).
 * ERR_VALUE_OUT_OF_RANGE, removed in d022cb1 (PR #17648).

PR-URL: #21491
Reviewed-By: Michaël Zasso <targos@protonmail.com>
Reviewed-By: Rich Trott <rtrott@gmail.com>
Reviewed-By: James M Snell <jasnell@gmail.com>
Reviewed-By: Michael Dawson <michael_dawson@ca.ibm.com>
Reviewed-By: Colin Ihrig <cjihrig@gmail.com>
Reviewed-By: Joyee Cheung <joyeec9h3@gmail.com>
Reviewed-By: Anatoli Papirovski <apapirovski@mac.com>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
lib / src Issues and PRs related to general changes in the lib or src directory. 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.

errors: similar error codes [VALUE_OUT_OF_RANGE] and [OUT_OF_RANGE]