- From: Ian Hickson <ian@hixie.ch>
- Date: Tue, 30 Mar 2010 07:20:41 +0000 (UTC)
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 later. -- Ian Hickson U+1047E )\._.,--....,'``. fL http://ln.hixie.ch/ U+263A /, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Received on Tuesday, 30 March 2010 00:20:41 UTC