- From: Aaron Boodman <aa@google.com>
- Date: Mon, 22 Jun 2009 17:55:46 -0700
- To: public-webapps@w3.org
This is an issue dear to my heart. I hate bad error reporting. Whether passing the wrong number of arguments is an error conceptually is a philosophical issue that I don't think we'll be able to agree on. In my opinion surfacing obvious errors to developers is a good thing that we should do. I understand this is not what JavaScript does, but I think that breaking with JavaScript here is a Good Thing. For those that agree that this is an error, that leaves us the question of how to report it. Exceptions would be best because that is how most other errors are already reported today, so it would be least surprising. It also has the benefit that there is already knowledge and code that looks for exceptions. But there is also an issue of legacy code. I brought this issue up in a webkit bug awhile ago, and one concern from the webkit developers was that introducing an exception would almost certainly "break" sites. My opinion is that those sites are almost certainly already broken. As a simple example, consider the setAttribute() method. Both arguments are required, but in WebKit, if you don't pass either value it is coerced to string. So if we take a simple attribute like "title": someElement.setAttribute("title"); // throws in Firefox, sets title to "undefined' in WebKit Philosophically, I want to say that pages that are passing too few arguments to DOM APIs are already broken, just in less obvious ways. Breaking in more obvious ways would be better. But if there is a concern about throwing, there is a third option: We could report the incorrect API usage to the console. This falls outside WebIDL's scope, but it would address the majority of my concern. - a
Received on Tuesday, 23 June 2009 00:56:22 UTC