This is an archived snapshot of W3C's public bugzilla bug tracker, decommissioned in April 2019. Please see the home page for more details.

Bug 23346 - Use TypeError for argument validation
Summary: Use TypeError for argument validation
Status: RESOLVED WONTFIX
Alias: None
Product: WebAppsWG
Classification: Unclassified
Component: XHR (show other bugs)
Version: unspecified
Hardware: PC All
: P2 normal
Target Milestone: ---
Assignee: Anne
QA Contact: public-webapps-bugzilla
URL:
Whiteboard:
Keywords:
Depends on: 23367 24581
Blocks:
  Show dependency tree / graph
 
Reported: 2013-09-24 22:10 UTC by Anne
Modified: 2014-05-13 09:29 UTC (History)
6 users (show)

See Also:

Attachments

Description Anne 2013-09-24 22:10:21 UTC 
Rather than using a mix of DOMException and TypeError we should probably just use TypeError for argument validation.
Comment 1 Masatoshi Kimura 2013-09-25 13:22:54 UTC 
I don't think TypeError is appropriate for syntax errors in the header field.
Comment 2 Anne 2013-09-25 13:24:19 UTC 
Based on what? TypeError is what JavaScript uses for argument validation.
Comment 3 Masatoshi Kimura 2013-09-25 13:42:13 UTC 
What about non-ECMAScript bindings?
Comment 4 Anne 2013-09-25 13:53:26 UTC 
We have stopped caring about those.
Comment 5 Masatoshi Kimura 2013-09-26 14:15:10 UTC 
(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
Comment 6 Anne 2013-09-27 19:46:53 UTC 
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.
Comment 7 Anne 2013-10-24 13:59:36 UTC 
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?
Comment 8 Hallvord R. M. Steen 2014-02-28 09:46:16 UTC 
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?
Comment 9 Anne 2014-03-17 16:04:46 UTC 
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.
Comment 10 Simon Pieters 2014-05-13 07:29:50 UTC 
Please make the specs match each other.

See https://github.com/w3c/web-platform-tests/pull/974
Comment 11 Anne 2014-05-13 09:29:45 UTC 
I don't see what needs to be fixed on the WHATWG side here.