23346 2013-09-24 22:10:21 +0000 Use TypeError for argument validation 2014-05-13 09:29:45 +0000 1 1 1 Unclassified WebAppsWG XHR unspecified PC All RESOLVED WONTFIX P2 normal --- 23367 24581 1 annevk annevk hsteen jungkees mike public-webapps VYV03354 zcorpan public-webapps-bugzilla oldest_to_newest 93750 0 annevk 2013-09-24 22:10:21 +0000 Rather than using a mix of DOMException and TypeError we should probably just use TypeError for argument validation. 93789 1 VYV03354 2013-09-25 13:22:54 +0000 I don't think TypeError is appropriate for syntax errors in the header field. 93790 2 annevk 2013-09-25 13:24:19 +0000 Based on what? TypeError is what JavaScript uses for argument validation. 93792 3 VYV03354 2013-09-25 13:42:13 +0000 What about non-ECMAScript bindings? 93794 4 annevk 2013-09-25 13:53:26 +0000 We have stopped caring about those. 93883 5 VYV03354 2013-09-26 14:15:10 +0000 (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 93979 6 annevk 2013-09-27 19:46:53 +0000 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. 95305 7 annevk 2013-10-24 13:59:36 +0000 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? 101604 8 hsteen 2014-02-28 09:46:16 +0000 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? 102460 9 annevk 2014-03-17 16:04:46 +0000 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. 105815 10 zcorpan 2014-05-13 07:29:50 +0000 Please make the specs match each other. See https://github.com/w3c/web-platform-tests/pull/974 105823 11 annevk 2014-05-13 09:29:45 +0000 I don't see what needs to be fixed on the WHATWG side here.