[whatwg] Web Workers feedback

Ian Hickson ian at hixie.ch
Tue Mar 30 00:20:41 PDT 2010

On Mon, 29 Mar 2010, Jonas Sicking wrote:
> >
> > We could throw an exception, but that would make migrating from this 
> > not being supported to this being supported later a lot harder (you'd 
> > have to catch exceptions and then remove the nodes, rather than just 
> > doing null checks in the worker). I don't know that that's worth it.
> I don't see why it would be harder to add support for passing objects 
> later harder. I would say quite the opposite. People are more likely to 
> come to depend on objects down in an object graph being converted to 
> null, than they are to come to depend on that throwing an exception.

I agree that people are less likely to depend on exceptions. The problem 
is feature detection so that you can use the new feature (sending DOM 
nodes) in new clients without failing in old clients. When sending null 
it's easy; when raising exceptions, you have to have two different sends.

> Additionally, it's unlikely that converting to null is the fallback 
> behavior you want for downlevel clients. Likely you'd want to manually 
> serialize such objects and then parse them on the receiver side. In this 
> case too an exception would likely help you more than silently 
> converting to null.

It depends on how critical the DOM node is. If it's just a reference deep 
inside some nested structure, which the other side only uses as an 
additional hint rather than as a required component of the corresponding 
algorithm, it's simpler just to have the UA convert it to null.

So I guess it rather depends on what the use cases are. I don't really 
mind throwing an exception if that's what people think is better, but my 
impression has been that when we do that, it makes things more difficult 

Ian Hickson               U+1047E                )\._.,--....,'``.    fL
http://ln.hixie.ch/       U+263A                /,   _.. \   _\  ;`._ ,.
Things that are impossible just take longer.   `._.-(,_..'--(,_..'`-.;.'

More information about the whatwg mailing list