This is an archived snapshot of W3C's public bugzilla bug tracker, decommissioned in April 2019. Please see the home page for more details.
Rather than using a mix of DOMException and TypeError we should probably just use TypeError for argument validation.
I don't think TypeError is appropriate for syntax errors in the header field.
Based on what? TypeError is what JavaScript uses for argument validation.
What about non-ECMAScript bindings?
We have stopped caring about those.
(In reply to Anne from comment #2) > TypeError is what JavaScript uses for argument validation. That's untrue. JSON.parse will throw SyntaxError if the first argument is invalid as JSON. http://ecma-international.org/ecma-262/5.1/#sec-15.12.2 Also, the RegExp constructor will throw SyntaxError if the first argument is unparsable as a regular expression. http://ecma-international.org/ecma-262/5.1/#sec-15.10.4.1
The JSON bit is an admitted mistake. Using SyntaxError for RegExp is intentional I believe as it's intended for syntax errors in JavaScript source code.
So looking at https://github.com/whatwg/xhr/pull/12 and the other exceptions we have in the specification. Should we consolidate more? Maybe we should hold off on this one until exceptions have moved to IDL completely?
Anne, we have tests testing that the "right" error is being thrown. Now, moving the spec forward will eventually depend on conformance as determined by the test suite.. So you deciding to wait with this change puts us in a somewhat awkward position: do we ship tests that follow the spec-as-is but test for something we do *not* want the spec to say eventually? Or ship tests that contradict the spec in its current form?
Hallvord, I guess we should just not do this and avoid churn. However, given how IDL might change around ByteString and such we might have some exception changes down the road.
Please make the specs match each other. See https://github.com/w3c/web-platform-tests/pull/974
I don't see what needs to be fixed on the WHATWG side here.