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

fs: migrate more errors to internal/errors #17667

Closed
wants to merge 1 commit into from

Conversation

jasnell
Copy link
Member

@jasnell jasnell commented Dec 14, 2017

Next batch of fs type checking migrations to use internal/errors

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)

fs

@jasnell jasnell added fs Issues and PRs related to the fs subsystem / file system. semver-major PRs that contain breaking changes and should be released in the next major version. labels Dec 14, 2017
@jasnell jasnell added the errors Issues and PRs related to JavaScript errors originated in Node.js core. label Dec 14, 2017
@jasnell
Copy link
Member Author

jasnell commented Dec 14, 2017

@@ -782,6 +782,12 @@ Encoding provided to `util.TextDecoder()` API was not one of the
A `Promise` that was callbackified via `util.callbackify()` was rejected with a
falsy value.

<a id="ERR_FS_INVALID_SYMLINK_TYPE"></a>
Copy link
Member

Choose a reason for hiding this comment

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

I suspect this principle has been decided previously, but maybe not?:

Is it desirable to have such specific codes? Why not just ERR_INVALID_ARG_VALUE?

Copy link
Member Author

Choose a reason for hiding this comment

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

it's been debated and I'm good with it either way.

Copy link
Member

Choose a reason for hiding this comment

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

I'd be in favor of erring on the side of more general and you can always move to a more specific code later if it turns out it's really needed. But yeah, if there's fierce opinions on both sides, then ¯\(ツ)

if (isUint8Array(buffer)) {
if (position === undefined)
position = null;
if (typeof offset !== 'number')
offset = 0;
if (typeof length !== 'number')
length = buffer.length - offset;
const byteLength = buffer.byteLength;
if (offset > byteLength)
throw new errors.RangeError('ERR_OUT_OF_RANGE', 'offset');
Copy link
Contributor

Choose a reason for hiding this comment

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

ERR_OUT_OF_RANGE is reduced into ERR_VALUE_OUT_OF_RANGE in #17648. So here would be better to use ERR_VALUE_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.

+1

Copy link
Member

Choose a reason for hiding this comment

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

Copy link
Member Author

Choose a reason for hiding this comment

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

yep, was holding off a bit to see if/when #17648 was going to land.

Copy link
Member Author

Choose a reason for hiding this comment

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

oh.. right, and the latest updates remove the out of range errors anyway so this is no longer relevant ;-)

@@ -307,6 +307,7 @@ E('ERR_ENCODING_INVALID_ENCODED_DATA',
'The encoded data was not valid for encoding %s');
E('ERR_ENCODING_NOT_SUPPORTED', 'The "%s" encoding is not supported');
E('ERR_FALSY_VALUE_REJECTION', 'Promise was rejected with falsy value');
E('ERR_FS_INVALID_SYMLINK_TYPE', 'Invalid symlink type: %s');
Copy link
Member

Choose a reason for hiding this comment

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

It would justify this new error a bit more if the error message includes a list of valid symlink types

@jasnell
Copy link
Member Author

jasnell commented Dec 18, 2017

ping @nodejs/tsc

@jasnell
Copy link
Member Author

jasnell commented Dec 18, 2017

Chose to go with @joyeecheung's suggestion of a more specific error message. PTAL

@jasnell jasnell requested a review from a team December 19, 2017 15:34
@joyeecheung
Copy link
Member

@jasnell
Copy link
Member Author

jasnell commented Dec 21, 2017

Thank you @joyeecheung :-) ...

@nodejs/tsc ... need one more TSC sign off please.

@joyeecheung
Copy link
Member

joyeecheung commented Dec 21, 2017

Looks like there was something wrong with linux one, new linux one CI: https://ci.nodejs.org/job/node-test-commit-linuxone/11371/

lib/fs.js Outdated
throw new errors.TypeError('ERR_INVALID_ARG_TYPE', 'path',
['string', 'Buffer', 'URL']);
}
if (!Number.isInteger(uid))
Copy link
Member

Choose a reason for hiding this comment

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

Should we also check for uid >= 0? Same question for the other checks in this commit

Copy link
Member Author

Choose a reason for hiding this comment

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

I do believe that uid and gid both can be negative in some edge cases.

lib/fs.js Outdated
@@ -785,20 +785,27 @@ fs.write = function(fd, buffer, offset, length, position, callback) {
callback(err, written || 0, buffer);
}

var req = new FSReqWrap();
if (!Number.isInteger(fd))
throw new errors.TypeError('ERR_INVALID_ARG_TYPE', 'fd', 'number');
Copy link
Member

Choose a reason for hiding this comment

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

s/number/integer/

lib/fs.js Outdated
@@ -825,13 +832,22 @@ Object.defineProperty(fs.write, internalUtil.customPromisifyArgs,
// OR
// fs.writeSync(fd, string[, position[, encoding]]);
fs.writeSync = function(fd, buffer, offset, length, position) {
if (!Number.isInteger(fd))
throw new errors.TypeError('ERR_INVALID_ARG_TYPE', 'fd', 'number');
Copy link
Member

Choose a reason for hiding this comment

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

s/number/integer/

if (isUint8Array(buffer)) {
if (position === undefined)
position = null;
if (typeof offset !== 'number')
offset = 0;
if (typeof length !== 'number')
length = buffer.length - offset;
const byteLength = buffer.byteLength;
if (offset > byteLength)
throw new errors.RangeError('ERR_OUT_OF_RANGE', 'offset');
Copy link
Member

Choose a reason for hiding this comment

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

+1

@@ -1604,6 +1610,8 @@ Creation of a [`zlib`][] object failed due to incorrect configuration.
[`dgram.createSocket()`]: dgram.html#dgram_dgram_createsocket_options_callback
[`ERR_INVALID_ARG_TYPE`]: #ERR_INVALID_ARG_TYPE
[`EventEmitter`]: events.html#events_class_eventemitter
[`fs.symlink()`]: fs.html#fs_symlink
[`fs.symlinkSync()`]: fs.html#fs_symlinksymc
Copy link
Member

Choose a reason for hiding this comment

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

typo: symlinksync

@targos
Copy link
Member

targos commented Dec 21, 2017

General question about Number.isInteger checks: the check passes for values > 2^31-1 in JS land but not in C++ land. Should we guard for this?

Copy link
Member

@mcollina mcollina left a comment

Choose a reason for hiding this comment

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

LGTM with the nits already noted addresses

@bnoordhuis
Copy link
Member

the check passes for values > 2^31-1 in JS land but not in C++ land

Replacing IsInt32() and IsUint32() checks with Number.isInteger() is wrong. Their JS equivalents are x === x | 0 and x === x >>> 0 respectively.

Another issue with Number.isInteger() is that users can monkey-patch it.

@jasnell
Copy link
Member Author

jasnell commented Dec 21, 2017

Updated to address @bnoordhuis' feedback.

@mcollina and @joyeecheung ... please take another look.

@jasnell
Copy link
Member Author

jasnell commented Dec 21, 2017

Copy link
Member

@mcollina mcollina left a comment

Choose a reason for hiding this comment

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

LGTM with the nit above adressed.

if (isUint8Array(buffer)) {
if (position === undefined)
position = null;
if (typeof offset !== 'number')
offset = 0;
if (typeof length !== 'number')
length = buffer.length - offset;
const byteLength = buffer.byteLength;
if (offset > byteLength)
throw new errors.RangeError('ERR_OUT_OF_RANGE', 'offset');
Copy link
Member

Choose a reason for hiding this comment

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

return TYPE_ERROR("gid must be an unsigned int");
CHECK_GE(len, 3);
CHECK(args[1]->IsUint32());
CHECK(args[2]->IsUint32());
Copy link
Member

Choose a reason for hiding this comment

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

IsInt32 (both lines)

Copy link
Member

Choose a reason for hiding this comment

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

FChown is not changed in this PR and also gets Uint32Value(). Are you sure negative uid and gid are possible?

Copy link
Member Author

Choose a reason for hiding this comment

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

hmm... they are definitely theoretically possible but you're right. I'll keep these as uint32s

@jasnell
Copy link
Member Author

jasnell commented Dec 22, 2017

jasnell added a commit that referenced this pull request Dec 22, 2017
PR-URL: #17667
Reviewed-By: Joyee Cheung <joyeec9h3@gmail.com>
Reviewed-By: Matteo Collina <matteo.collina@gmail.com>
@jasnell
Copy link
Member Author

jasnell commented Dec 22, 2017

Landed in 6100e12

@jasnell jasnell closed this Dec 22, 2017
Copy link
Member

@targos targos left a comment

Choose a reason for hiding this comment

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

Belated LGTM

@apapirovski
Copy link
Member

@jasnell it looks like the new assertions in src/node_file.cc are causing some CitGM issues. Would you mind having a look? https://ci.nodejs.org/view/Node.js-citgm/job/citgm-smoker/1165/

@joyeecheung
Copy link
Member

@apapirovski The CITGM issues are caused by fs.readFile and fs.exists/fs.existsSync raising assertion when the path is undefined. I have a fix coming up.

apapirovski pushed a commit that referenced this pull request Dec 27, 2017
PR-URL: #17852
Refs: #17667
Reviewed-By: James M Snell <jasnell@gmail.com>
Reviewed-By: Colin Ihrig <cjihrig@gmail.com>
Reviewed-By: Matteo Collina <matteo.collina@gmail.com>
apapirovski pushed a commit that referenced this pull request Dec 27, 2017
PR-URL: #17852
Refs: #17667
Reviewed-By: James M Snell <jasnell@gmail.com>
Reviewed-By: Colin Ihrig <cjihrig@gmail.com>
Reviewed-By: Matteo Collina <matteo.collina@gmail.com>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
errors Issues and PRs related to JavaScript errors originated in Node.js core. fs Issues and PRs related to the fs subsystem / file system. 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.

8 participants