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

errors in punycode.js: assign codes or leave them alone? #27023

Closed
joyeecheung opened this issue Mar 31, 2019 · 7 comments
Closed

errors in punycode.js: assign codes or leave them alone? #27023

joyeecheung opened this issue Mar 31, 2019 · 7 comments
Labels
discuss Issues opened for discussions and feedbacks. errors Issues and PRs related to JavaScript errors originated in Node.js core.

Comments

@joyeecheung
Copy link
Member

From #11273 which is almost complete except this one.

All the errors thrown from there are RangeErrors for invalid input.

@joyeecheung joyeecheung added errors Issues and PRs related to JavaScript errors originated in Node.js core. discuss Issues opened for discussions and feedbacks. labels Mar 31, 2019
@bnoordhuis
Copy link
Member

Pro: easy change to make, all exceptions are thrown from the error() function.

Con: it's a third-party dependency that we vendor in, and deprecated to boot.

Personally, I'd be okay with floating a small patch. It's unlikely to be a maintenance hassle.

@BridgeAR
Copy link
Member

which is almost complete except this one

We still throw regular errors in

// eslint-disable-next-line no-restricted-syntax
var err = new Error(message);
err.code = 'MODULE_NOT_FOUND';
err.requireStack = requireStack;
throw err;
(even though we attach an error code but one that is not aligned with all other error codes). I wonder if we should ever port that to internal/errors as well?

@joyeecheung
Copy link
Member Author

@BridgeAR I guess the answer from my side is “if it does not involve any circular dependency zalgo (which I don’t think there is) then why not”.

Also this makes good first contributions so that’s a plus.

@targos
Copy link
Member

targos commented Mar 31, 2019

Isn't the issue with MODULE_NOT_FOUND that this code is used since forever (I could find it in v0.10) and it would be a major breaking change for the ecosystem to change it?

@BridgeAR
Copy link
Member

@targos yes, I also checked 0.8 and it's even used in there. I also checked Gzemnid and userland seems to check for the code frequently. I guess we could open a couple PRs to change the check to check for two codes and as soon as most modules adopted to that strategy to change the error code but otherwise it's hard to do that. We could also stick to the current error code but still migrate it to our internal errors (just with the old error code that doesn't match the new ones).

@jasnell
Copy link
Member

jasnell commented Mar 31, 2019

I would leave punycode.js untouched as it is deprecated and only used by node.js when node.js is built without ICU.

@jasnell
Copy link
Member

jasnell commented Jun 26, 2020

There's been no further activity on this. Closing. If necessary we can revisit this

@jasnell jasnell closed this as completed Jun 26, 2020
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
discuss Issues opened for discussions and feedbacks. errors Issues and PRs related to JavaScript errors originated in Node.js core.
Projects
None yet
Development

No branches or pull requests

5 participants