-
Notifications
You must be signed in to change notification settings - Fork 165
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
Should DOMException.[[Prototype]] be %Error%? #1107
Comments
I don't think this is really intentional. It's just a historical artifact of how DOMException has custom bindings, and nobody ever implemented this. See #378 and in particular the second comment there. IMO we should change this and it shouldn't be risky. |
I think changing this should be relatively easy for Gecko. |
I think that we can ask V8 team to expose the v8::FunctionTemplate of |
Summary of work to be done here:
|
The custom bindings for DOMException specify that DOMException.prototype.[[Prototype]] is %Error.prototype%. However it doesn’t also set DOMException.[[Prototype]] to %Error%, so instead it ends up with %Function.prototype%, which is what would occur for a “base” constructor.
This seems to make DOMException a pretty peculiar outlier. Among ECMAScript intrinsics, there are no cases where F.prototype.[[Prototype]] and F.[[Prototype]].prototype both exist yet point at different values. In Web IDL, this does also occur with
[LegacyFactoryFunction]
but in these cases, F.prototype.constructor isn’t actually F (and F does exhibit the normal pattern), so it’s relatively tough to run into the difference. In any case, scanning for it among globals suggests that DOMException’s constructor-prototype relationship is likely a true one-off:(code from image)
Among other quirks, this means
Error[@@hasInstance]
andError.isPrototypeOf
tell unexpectedly different stories about the relationship between Error and DOMException.Is DOMException’s departure from the typical prototype inheritance pattern intentional? It seems like the sort of thing that could plausibly have been necessitated by a web compat issue, but I didn’t turn up any history on it, and it also seems plausible that it was an oversight and actually should be specified to inherit from %Error%.
The text was updated successfully, but these errors were encountered: