buffer,error: improve bigint, big numbers and more #27228
Conversation
This comment has been minimized.
This comment has been minimized.
nodejs-github-bot
added
buffer
|
Why not use https://github.com/tc39/proposal-numeric-separator instead? Then the number displayed can be copy-pasted and evaluated again when our copy of v8 ships it. (It's already shipped in the upstream) |
How does that apply here? If I read the spec correct it's only about allowing underscores in numbers in code. But this changes the way they are displayed in our errors. |
|
@BridgeAR Sorry, I was not being clear, I meant using the format of the proposal (that is, using underscores) instead of using |
|
@joyeecheung ah, I don't think that's a good idea. AFAIK the format is used in code because it is not used for anything else in program code (the dot is used as decimal separator). The error is of course meant for developers but I think commas are still nicer to read. |
But the syntax in the spec is also meant for developers? It seems when Node.js is built with full ICU the return value of |
This improves the error message from `ERR_OUT_OF_RANGE` by closer inspecting the value and logging numbers above 2 ** 32 by adding commas to the output for integer and bigint. BigInt is now also marked if used. Buffer errors also format the range as 2 ** n instead of showing a huge number.
BridgeAR
force-pushed
the
improve-err-out-of-range-message
branch
from
3e88505
to
8dd4ba0
Compare
|
I updated the PR not to use |
I see. That does make sense. I suggest we could change the format as soon as Node.js actually supports the underscores. Before that, I fear it would confuse people more than help? |
This comment has been minimized.
This comment has been minimized.
SGTM, though I believe that's going to be just a month from now since it's shipped in M75. https://chromiumdash.appspot.com/schedule |
But it takes time until we actually ship that and until users get to know the new notation. I don't think switching right away is best. And this would only be possible for Node.js v12 while this only changes the error message and is a patch. |
This comment has been minimized.
This comment has been minimized.
I think Node.js is in the position to help promoting new features like this, instead of waiting for its adoption, considering this is a runtime where many developers get to try new language features first without transpilation - when there is a new release comes out with a V8 update we tend to mention what language feature is now available and AFAIK many people get to know that a feature is ready through this. Since it's already shipped in the upstream, it's quite unlikely that this feature is going away, and we are not in the position to control what v8 unflags by default so it's going out soon, it seems a bit odd to me that Node.js itself has to wait for adoption considering it is a channel to promote adoption - user land frameworks (both frontend and backend) are even more agressive in terms of promoting new features that are not even stable in the standardization process. |
|
@joyeecheung if you think that's the best way: I am fine to change it for Node.js v12 and up but this PR is not semver-major and can be backported. I think it's best to only use that format in case that Node.js version actually supports it. |
|
If this is changing the output from a format that can be copy-pasted in code into something that cannot...I am not sure it's actually an improvement? |
BridgeAR
requested review from
addaleax,
richardlau and
joyeecheung
and removed request for
richardlau
|
@bnoordhuis @richardlau would either of you be so kind to confirm your LG due to the changed implementation? This should otherwise be good to go. |
|
This could use one more LG before landing / confirming the LG. // cc @nodejs/buffer |
This improves the error message from `ERR_OUT_OF_RANGE` by closer inspecting the value and logging numbers above 2 ** 32 by adding commas to the output for integer and bigint. BigInt is now also marked if used. Buffer errors also format the range as 2 ** n instead of showing a huge number. PR-URL: nodejs#27228 Reviewed-By: Richard Lau <riclau@uk.ibm.com> Reviewed-By: Ben Noordhuis <info@bnoordhuis.nl> Reviewed-By: Michaël Zasso <targos@protonmail.com>
|
Thanks for the reviews. Landed in 4416127 🎉 |
This improves the error message from `ERR_OUT_OF_RANGE` by closer inspecting the value and logging numbers above 2 ** 32 by adding commas to the output for integer and bigint. BigInt is now also marked if used. Buffer errors also format the range as 2 ** n instead of showing a huge number. PR-URL: #27228 Reviewed-By: Richard Lau <riclau@uk.ibm.com> Reviewed-By: Ben Noordhuis <info@bnoordhuis.nl> Reviewed-By: Michaël Zasso <targos@protonmail.com>
This improves the error message from `ERR_OUT_OF_RANGE` by closer inspecting the value and logging numbers above 2 ** 32 by adding commas to the output for integer and bigint. BigInt is now also marked if used. Buffer errors also format the range as 2 ** n instead of showing a huge number. PR-URL: nodejs/node#27228 Reviewed-By: Richard Lau <riclau@uk.ibm.com> Reviewed-By: Ben Noordhuis <info@bnoordhuis.nl> Reviewed-By: Michaël Zasso <targos@protonmail.com>
This improves the error message from
ERR_OUT_OF_RANGEby closerinspecting the value and logging numbers above 2 ** 32 by using
toLocaleStringand a similar output for bigint. BigInt is now alsomarked if used.
Buffer errors also format the range as 2 ** n instead of showing a
huge number.
Checklist
make -j4 test(UNIX), orvcbuild test(Windows) passes