W3C home > Mailing lists > Public > public-webapps@w3.org > April to June 2009

Re: Handling too few arguments in method calls

From: Aaron Boodman <aa@google.com>
Date: Mon, 22 Jun 2009 17:55:46 -0700
Message-ID: <278fd46c0906221755l2c8196fasec3f5eb763cda07a@mail.gmail.com>
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 GMT

This archive was generated by hypermail 2.3.1 : Tuesday, 26 March 2013 18:49:31 GMT