Join GitHub today
GitHub is home to over 50 million developers working together to host and review code, manage projects, and build software together.
Sign upGitHub is where the world builds software
Millions of developers and companies build, ship, and maintain their software on GitHub — the largest and most advanced development platform in the world.
lib/querystring: convert to using internal/errors #15565
Conversation
|
This needs a test and the error type should not change. |
| @@ -178,7 +179,7 @@ function qsEscape(str) { | |||
| if (i < str.length) | |||
| c2 = str.charCodeAt(i) & 0x3FF; | |||
| else | |||
| throw new URIError('URI malformed'); | |||
| throw new errors.TypeError('ERR_QUERYSTRING_URI_INVALID', 'URI malformed'); | |||
BridgeAR
Sep 23, 2017
Member
The error type URIError should stay as it is. If that type does not yet exist in the internal/errors it has to be created.
Out of my perspective a better name for the internal type would also be ERR_INVALID_URI (I am still thinking about if it would be a good idea to combine this with the existing ERR_INVALID_URL type or not) and the error message itself should be moved in the internal errors as static value.
The error type URIError should stay as it is. If that type does not yet exist in the internal/errors it has to be created.
Out of my perspective a better name for the internal type would also be ERR_INVALID_URI (I am still thinking about if it would be a good idea to combine this with the existing ERR_INVALID_URL type or not) and the error message itself should be moved in the internal errors as static value.
refack
Sep 23, 2017
•
Member
As a temporary workaround this could be done with:
else {
const e = new URIError('URI malformed');
e.code = 'ERR_INVALID_URI';
throw e;
}
As a temporary workaround this could be done with:
else {
const e = new URIError('URI malformed');
e.code = 'ERR_INVALID_URI';
throw e;
}
refack
Sep 23, 2017
Member
Since this is the only place in /lib/ where URIError is used, I'm not sure it should not be changed...
/cc @jasnell
Since this is the only place in /lib/ where URIError is used, I'm not sure it should not be changed...
/cc @jasnell
BridgeAR
Sep 25, 2017
Member
This recommendation is bad out of my perspective. It is not similar to the internal/errors by just adding the error code. It is neither a NodeError, nor would it receive any further changes in case something changes in the internal/errors.
I would also like to keep the error type as URIError even if it is the only occurrence in lib. It is a single line that has to be added to the internal/errors to add that type and use it from then on.
This recommendation is bad out of my perspective. It is not similar to the internal/errors by just adding the error code. It is neither a NodeError, nor would it receive any further changes in case something changes in the internal/errors.
I would also like to keep the error type as URIError even if it is the only occurrence in lib. It is a single line that has to be added to the internal/errors to add that type and use it from then on.
ramimoshe
Sep 26, 2017
•
Author
Contributor
|
@ramimoshe Thanks a lot for your PR! This goes in the right direction and just needs a bit more work |
|
thanks, |
| @@ -261,7 +261,7 @@ E('ERR_NO_LONGER_SUPPORTED', '%s is no longer supported'); | |||
| E('ERR_OUT_OF_RANGE', 'The "%s" argument is out of range'); | |||
| E('ERR_OUTOFMEMORY', 'Out of memory'); | |||
| E('ERR_PARSE_HISTORY_DATA', 'Could not parse history data in %s'); | |||
| E('ERR_QUERYSTRING_URI_INVALID', '%s'); | |||
| E('ERR_INVALID_URL', 'URI malformed'); | |||
refack
Sep 23, 2017
Member
So we have a new lint rule that makes sure the error code are sorted in ASCIIbetical order.
It would have made you notice https://github.com/nodejs/node/blob/4518d94e6104323b06781ba608e59208d35a6129/lib/internal/errors.js#L243
So IMHO make this ERR_INVALID_URI (so that we can keep the message text the same), and move it to L243 above the previous ERR_INVALID_URL
So we have a new lint rule that makes sure the error code are sorted in ASCIIbetical order.
It would have made you notice https://github.com/nodejs/node/blob/4518d94e6104323b06781ba608e59208d35a6129/lib/internal/errors.js#L243
So IMHO make this ERR_INVALID_URI (so that we can keep the message text the same), and move it to L243 above the previous ERR_INVALID_URL
|
Thanks for following up. common.expectsError(
() => qs.stringify({ foo: '\udc00' }),
{
code: 'ERR_INVALID_URI',
type: TypeError,
message: 'URI malformed'
}
);or just as the validator for common.expectsError({
code: 'ERR_INVALID_URI',
type: TypeError,
message: 'URI malformed'
});
|
| if (i < str.length) | ||
| c2 = str.charCodeAt(i) & 0x3FF; | ||
| else | ||
| throw new URIError('URI malformed'); |
BridgeAR
Sep 25, 2017
Member
I would definitely recommend to change this to use internal/errors but it should be kept as URIError as I mentioned above (#15565 (comment)).
I would definitely recommend to change this to use internal/errors but it should be kept as URIError as I mentioned above (#15565 (comment)).
|
@refack // invalid surrogate pair throws URIError
assert.throws(function() {
qs.stringify({ foo: '\udc00' });
}, /^URIError: URI malformed$/); StackTrace from the test (after changing):
|
|
@ramimoshe you can not update the The error type should definitely not be changed because it would be inconsistent in that case what error we might return. Please switch back to the |
|
Ping @ramimoshe |
|
This is how you can add the URIError to the module.exports = exports = {
message,
Error: makeNodeError(Error),
TypeError: makeNodeError(TypeError),
RangeError: makeNodeError(RangeError),
URIError: makeNodeError(URIError), // <----
AssertionError,
E // This is exported only to facilitate testing.
};And this is how you would use it in a different file. const errors = require('internal/errors');
// ...
throw new errors.URIError('ERR_INVALID_URI'); |
|
I think I have brought this up in a URL PR before but couldn't find the link. The ECMAScript spec says (Going to board so no time to dig the link to spec) |
|
I couldn't find a reference in the ECMAScript spec (image because the spec takes a while to load) The Web IDL spec only excludes |
|
@ramimoshe, sorry for the delay.
Use node/test/parallel/test-zlib-not-string-or-buffer.js Lines 10 to 18 in b050c14 |
|
@refack IMO
means it excludes user land methods from throwing a Anyway, I am still fine with throwing |
|
This would need to update |
|
Also, |
|
@joyeecheung do you know the issue with ubuntu1404-64 build? |
|
@ramimoshe Nope, looks like a flake because the failing test should not go through the query string module. |
|
@joyeecheung do i have to do something or just wait to approving? |
|
@ramimoshe This is semver-major so needs at least 2 TSC approvals... @nodejs/tsc |
|
CI before landing: https://ci.nodejs.org/job/node-test-pull-request/11040/ |
|
https://ci.nodejs.org/job/node-test-linter/13033/console
@ramimoshe Do you have time to document this error code? If not I can do that, just don't want to delay this PR for too long. |
|
@joyeecheung - yes, i will fix it |
|
LGTM if CI is green: https://ci.nodejs.org/job/node-test-pull-request/11053/ |
PR-URL: #15565 Reviewed-By: Refael Ackermann <refack@gmail.com> Reviewed-By: James M Snell <jasnell@gmail.com> Reviewed-By: Joyee Cheung <joyeec9h3@gmail.com> Reviewed-By: Gireesh Punathil <gpunathi@in.ibm.com>
|
@ramimoshe Thanks! |
PR-URL: nodejs/node#15565 Reviewed-By: Refael Ackermann <refack@gmail.com> Reviewed-By: James M Snell <jasnell@gmail.com> Reviewed-By: Joyee Cheung <joyeec9h3@gmail.com> Reviewed-By: Gireesh Punathil <gpunathi@in.ibm.com>
PR-URL: nodejs/node#15565 Reviewed-By: Refael Ackermann <refack@gmail.com> Reviewed-By: James M Snell <jasnell@gmail.com> Reviewed-By: Joyee Cheung <joyeec9h3@gmail.com> Reviewed-By: Gireesh Punathil <gpunathi@in.ibm.com>
PR-URL: nodejs/node#15565 Reviewed-By: Refael Ackermann <refack@gmail.com> Reviewed-By: James M Snell <jasnell@gmail.com> Reviewed-By: Joyee Cheung <joyeec9h3@gmail.com> Reviewed-By: Gireesh Punathil <gpunathi@in.ibm.com>


covert lib/querystring.js over to using lib/internal/errors.js
ref: #11273