- From: Jonas Sicking <jonas@sicking.cc>
- Date: Mon, 16 Jun 2008 14:13:08 -0700
- To: Zhenbin Xu <Zhenbin.Xu@microsoft.com>
- CC: Sunava Dutta <sunavad@windows.microsoft.com>, Web API public <public-webapi@w3.org>, IE8 Core AJAX SWAT Team <ieajax@microsoft.com>, "public-webapps@w3.org" <public-webapps@w3.org>
Zhenbin Xu wrote: > The issue of return "null or an exception" is simply a compromise > here. IE would throw an exception for state violations. Accessing > responseXML before open() is a state violation so it would trigger > exception. Other browsers may return null in such situation. In order > to accommodate all browsers, the spec would have to be rewritten in > some way. Please note that it is not a goal for the spec to be written in such a way that all existing browsers are conforming to the spec. It turned out that it was impossible to write a spec with that goal while still keeping the spec useful. So we no longer try to "accomodate all browsers", but instead write a spec that leads to interoperability between browsers. > We would certainly love to have the spec change to "MUST throw > INVALID_STATE_ERR exception", which is consistent with other > INVALID_STATE_ERR cases. For instance, the spec says if send() is > called before OPENED, it should trigger INVALID_STATE_ERR exception. > Another example is that user agent must raise INVALID_STATE_ERR if > "status" is not available. responseText and responseXML are the > outlier in the spec. Personally I think it makes more sense to return 'null' from .responseXML. We at mozilla have not had any interoperability problems with this behavior. Exceptions are better left for exceptional circumstances. However I can't say that I think the behavior is very important to me one way or another, as long as it's usefully defined. Best Regards, Jonas Sicking
Received on Monday, 16 June 2008 21:17:02 UTC