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. `._.-(,_..'--(,_..'`-.;.'