Re: [WebIDL] Allowing specifications to opt in to throwing on sets of enumerated attributes to invalid values

On Thursday, 15 November 2012 at 01:32, Boris Zbarsky wrote:

> Right now, if you have an attribute declared with an enum type, setting  
> it to a value not in the enumeration is silently ignored. While this is  
> a behavior that matches legacy XMLHttpRequest and HTML attributes, going  
> forward specifications may want to throw on invalid values instead.
>  
> So I'd like to propose an extended attribute on either the IDL attribute  
> or the enum itself to opt in to always throwing on invalid values.
>  
> Thoughts?

This sounds ok to me, but did you have any particular cases in mind?  

The only concern I have is that it could affect compatibility in that it kinda introduces versioning (and then need to then wrap all code in try/catch blocks).  

lets say V1:

enum FooTypes { "fu", "foo" };

And V2 :  
enum FooType { "fu", "foo", "foofoo" };



And V3:  
enum FooType { "fu", "foo", "foofoo", "foh" };



interface Foo{
[strict] attribute FooType bar;  
};



If I don't know which version of the API introduced which FooType, running in a legacy browser that supports V1 will throw for values valid in V2 and V3. Also, an author writing code for V1 might not even know that the API throws when given a bogus value (or a value that appears to be bogus in V1, but is perfectly valid in V2, V3, Vn).   

Worst case, you end up with something like:

try{
fooObj.bar = value;  
//did it really assign the value?  
if(fooObj.bar === value){
//...do interesting stuff…   
}
}catch(e){
//oh dear, what version of the API is this?  
...
}

--  
Marcos Caceres
http://datadriven.com.au

Received on Thursday, 15 November 2012 12:00:15 UTC