-
Notifications
You must be signed in to change notification settings - Fork 436
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
[js-api] Constructor requirements for Error Objects violate ecma262 assertions #1549
Comments
Good points. There's two questions here: the first is what the behaviour should be, and the second is how to spec it. For (1), I think the current implementation consensus is "do whatever NativeError does, except expose the constructors on For (2), I guess I could add an explicit delta to the intrinsics table and the note, or we could talk to the ES editors to loosen the language. My personal preference would be to sidestep all this and remove these exception APIs altogether, but I fear it's too late for that. |
In https://webassembly.github.io/spec/js-api/#error-objects the constructor steps say to "implement the NativeError Object Structure"
In the NativeError() steps in ecma262 https://tc39.es/ecma262/#sec-nativeerror , it says to call OrdinaryCreateFromConstructor:
This implies that we're supposed to call OrdinaryCreateFromConstructor with intrinsicDefaultProto set to "%CompileError.prototype%", "%LinkError.prototype%", and "%RuntimeError.prototype%", like so:
OrdinaryCreateFromConstructor(newTarget, "%CompleError.prototype%", <<[[ErrorData]]>>)
However, step 1 of OrdinaryCreateFromConstructor https://tc39.es/ecma262/#sec-ordinarycreatefromconstructor says:
Seeing as we're in the ecma262 specification, and "%CompileError.prototype%" is not "this specification"'s name of an intrinsic object, we've failed the assertion.
Also , the note for NativeError() states:
This implies (to me) that the ecma262 authors intended for NativeError to be a closed set of types.
Is the intent of the WebAssembly spec steps to "duck type" these 3 error types so that they look like NativeError? Or are implementers supposed to actually implement all of the spec steps for NativeError, and disregard the note, and the spec assertions in both OrdinaryCreateFromConstructor and GetPrototypeFromConstructor that it calls? Or is this a more general ecma262 problem that a bunch of the spec AOs assume that extension specs are not a thing?
This came up when trying to implement the Error types in SerenityOS's LibWeb and LibJS here: SerenityOS/serenity#15248 (comment) where the assertion is enforced at compile time by passing a function pointer to one of JS::Intrinsics's member functions:
LibJS implementation of OrdinaryCreateFromConstructor and GetPrototypeFromConstructor
The text was updated successfully, but these errors were encountered: