Skip to content

Potential webcompat fallout #11

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

Open
miketaylr opened this issue Oct 30, 2018 · 2 comments
Open

Potential webcompat fallout #11

miketaylr opened this issue Oct 30, 2018 · 2 comments

Comments

@miketaylr
Copy link

hi everybody. 👋

I recently wrote about some error message changes we had to back out of Firefox, because the new changes broke sites that made assumptions about what certain type error messages look like:

https://miketaylr.com/posts/2018/10/(native)-error-prototype-message.html

One site was able to fix their own code, but the larger concern is sites using facebook' idx library (and of course, the things we don't know about:

https://github.com/facebookincubator/idx/blob/9609fe1a728caaea8f621c44e2e7190a1c5689f6/packages/idx/src/idx.js#L73-L84

So anyways, it would be useful to probably do a bit of research or outreach to increase the odds of any proposed improvements sticking.

@littledan
Copy link
Collaborator

I believe there has been even more strong reliance on the particular shape of error messages in Node.js, since there is a single JS implementation in common use there. cc @joyeecheung

I wonder if we could make some of these error messages richer in DevTools while keeping their .message similar, or something like that.

@joyeecheung
Copy link

joyeecheung commented Oct 30, 2018

Node.js has partly mitigated the problem by providing a stronger stability guarantee through err.code - prior to the introduction of the new error code system every changes to the error message (even typo fixes) had to be marked as semver-major. Now the errors migrated to the new error code system can have their message changed without going semver-major as long as the err.code stays the same. Users are encouraged to use err.code instead of parsing err.message to detect the type of errors as they wish.

Not every error in Node.js has been migrated to the new system, though - there are still some errors thrown in the C++ land without err.code, and for compatibility reasons, some errors use libuv error codes as err.code.

IIRC @jasnell was considering a proposal to ECMAScript to officially endorse error.code somehow, but I am not sure how the change to the spec is going to look like. Also outside of Node.js, on the Web the DOMExceptions have integers as err.code (though those are legacy codes).

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants