-
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
Constructing DOMException with causes #969
Comments
I guess the one question here is whether it should overload the second argument or become a third argument. |
For my part, I'm quite supportive. (Perhaps not surprising given my original pitch at tc39/proposal-error-cause#10 (comment) 🙂.) IMO it should overload the second argument with a name-containing dictionary member. That allows more uniform usage of error constructors, as I explained in the link above. It makes |
cc @jasnell |
Overloading the second argument is good, I think. Makes things pretty straightforward. |
The proposal for adding an additional option bag to ECMAScript Error constructor to construct errors with a cause property has reached stage 3 in the TC39 proposal process. The proposal is seeking for chaining logically related errors without losing their context information like messages, properties, and stacks.
There are discussions that
DOMException
can also adopt the signature (by overloading the second parametername
to with an object as the option bag) so that DOMException on the Web and Error in ECMAScript can be constructed with similar parameters.As the proposal error cause has reached stage 3 and implementations have been trying to land the proposal (chakra-core/ChakraCore@b992a5d, WebKit/WebKit@b03c4f4), I'm opening this issue here seeking feedbacks on the
DOMException
changes.The text was updated successfully, but these errors were encountered: