if converting a JS argument to the type declared in the IDL file throws an exception, the auto-generated code will throw a TYPE_MISMATCH_ERR. so i think we just need to change toJS/toV8 to throw exceptions when conversions fails instead of returning NULL (toString(), toInt32(), etc. already do that).
dumi On Wed, Aug 11, 2010 at 11:10 PM, Mo, Zhenyao <[email protected]> wrote: > Actually it's a different issue. What we want to do is not enforcing > full arguments, but if an input argument is the wrong type, we raise a > TypeError. > > Mo > > On Wed, Aug 11, 2010 at 7:13 PM, Adam Barth <[email protected]> wrote: > > This sounds related to the recent addition of > > [RequiresAllArguments=Raise]. Historically, we've been lax about > > missing arguments. I think the specs want us to be stricter, but last > > time we discussed the topic, the read I got was that the compatibility > > pain might not be worth the benefit. > > > > Adam > > > > > > On Wed, Aug 11, 2010 at 7:06 PM, Mo, Zhenyao <[email protected]> wrote: > >> Currently for a function's signature in WebKit, if an argument's type > >> is a wrapper type (those JS objec ts that wrap c++ objects, for > >> example, JSWebGLProgram, JSCSSRule, etc.) and if the input object's > >> type does not match the signature, the input is casted to null and no > >> TypeError is raised. > >> > >> Even though WebKit doesn't use Web IDL specially, I think we can look > >> to the Web IDL spec for guidance on what the behavior should be. > >> According to Web IDL spec (http://dev.w3.org/2006/webapi/WebIDL/), > >> unless [AllowAny] is put in the signature, an TypeError should be > >> raised if an argument type does not match its signature. The new > >> automatic code generation for overloaded functions in WebKit DOES > >> raise TypeError when it fails to determine which overloaded variant to > >> call. > >> > >> We definitely need to do the strict type checking for WebGL functions. > >> However, changing the default behavior of the IDL code generators > >> might have a significant compatibility impact. It isn't clear to us > >> whether the current behavior is intentional. If yes, please let us > >> know and we will try to fix the WebGL part only. Otherwise we will > >> modify the general rule instead. > >> _______________________________________________ > >> webkit-dev mailing list > >> [email protected] > >> http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev > >> > > > _______________________________________________ > webkit-dev mailing list > [email protected] > http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev >
_______________________________________________ webkit-dev mailing list [email protected] http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
