[whatwg] Web Workers feedback

[Jonas Sicking]

On Tue, Mar 30, 2010 at 3:09 PM, Ian Hickson <ian at hixie.ch> wrote:
> 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?

I think fallback is to be considered an exceptional case. Especially
as time goes on and more browsers implement support for the new type.

>> 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.

Say sending a DOM that the user has edited (using contentEditable)
which the worker will convert into a ODF document and send to the
server.

>> 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.

It just seems unlikely to me that people send data without actually
needing to. If someone does postMessage(X), then I would think they
intend to use X on the other end, be that if X is a DOM Node object or
a JS Array.

"they probably intended to say postMessage(Y)" seems as likely as
"they probably meant to appendChild(X)".

>> 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?

For circular object graphs in the very same algorithms. So

var a = {};
a.x = a;
worker.postMessage(a);

throws an exception.

/ Jonas