[whatwg] Web Workers feedback

[Ian Hickson]

On Tue, 30 Mar 2010, Jonas Sicking wrote:
> >
> > 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.
> 
> I would rather argue that throwing an exception makes feature detection 
> simpler. That way you can do something like:
> 
> try {
>   w.postMessage(obj);
> } catch() {
>   var f = {};
>   f.x = obj.x;
>   f.y = obj.y;
>   f.complex = serializeOrCreateOtherFallback(obj.complex);
>   w.postMessage(f);
> }

My understanding was that relying on exceptions for non-exceptional cases 
is bad API design. Why would it be ok here?


> If null is sent you have to inside the worker send back an error message 
> to the sender. The sender has to find the correct data to send, which 
> could be hard given that the error message is received asynchronously, 
> and then resend.

I agree that if you need the data either way, that sending null is 
useless. There are simple work-arounds for this (for example, sending one 
DOM node in a test message and having the worker let you know if it worked 
or not, so that you can construct the right class of object to handle the 
communication: one that sends DOM nodes or one that constructs the 
relevant data), but of course they are not ideal, just like using 
exceptions everywhere isn't ideal.

The question is, what are the actual concrete cases where people will be 
sending DOM nodes? Without concrete cases, it's easy to construct 
artificial cases that prove this to be better one way or the other.


> Ok, I guess it comes down to if we think it's more likely that people 
> will send Nodes and other unsupported objects by accident or as optional 
> data, or because they really want to send them.

Yes.


> Personally my guess it's more likely that they really wanted to.

I have no idea which is more likely. The only use case I'm aware of is 
passing an <img> in, and for that there isn't really a fallback position, 
so it doesn't matter if we send null or throw an exception.


On Tue, 30 Mar 2010, Sigbjorn Finne wrote:
> 
> At Opera, we've gone back and forth on what's the preferable behaviour 
> here (previous spec versions did choose exceptions, I believe.) A third 
> option, and the traditional way of solving serialisation extensibility, 
> is to define an interface that host objects then need to implement to be 
> cloneable. Extra machinery.
> 
> Which one? Tempting to say that this it is a property of the host 
> language; returning 'null' fits non-strict EcmaScript one might argue, 
> exceptions its strict mode (such as it is/might become.) Languages that 
> provide more sophisticated type systems and enforcement might do a 
> better job.

I really don't think we want to even have a strict mode (just look at the 
mess it's given us in HTML!), so I am not of the opinion that we should 
add extra things that depend on that mode.


> Personally, I think throwing an exception fits in with the spec's use of 
> them elsewhere (i.e., cross-document and web workers.)

Where do we use exceptions for extension points in a similar way?

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