Re: responseXML/responseText exceptions and parseError

Anne van Kesteren wrote:
> 
> On Tue, 17 Jun 2008 10:29:12 +0200, Zhenbin Xu 
> <Zhenbin.Xu@microsoft.com> wrote:
>> Technically because all other XHR methods/properties throw exceptions
>> in case of state violation, exception for responseXML/responseText is 
>> better.
> 
> The reason these don't throw an exception anymore is actually documented 
> on the public-webapi mailing list. Nobody else provided additional 
> information at the time:
> 
> http://lists.w3.org/Archives/Public/public-webapi/2008Feb/thread.html#msg94
> 
> Regarding parseError, since the parseError object is not part of DOM 
> Core and nobody but Internet Explorer supported it, it's not part of 
> XMLHttpRequest.

Agreed.

> If we change DOM Core to say that documents with a 
> namespace well-formedness violation are represented by an empty Document 
> object with an associated parseError object I suppose we could update 
> XMLHttpRequest to that effect.

If we return null now people will use that to check for well-formedness 
checks. If we in the next version of the spec then said that an empty 
document with .parseError set should be returned those pages would break.

So if we are planning on doing the parse error thing then I think we 
should define that an empty document is returned.

Though I think it's more friendly to JS developers to return null. 
Otherwise they have to nullcheck both .responseXML as well as 
.responseXML.documentElement in order to check that they have a valid 
document.

And if I understand it right IE would have to be changed to be complient 
with the spec no matter what since they currently return a non-empty 
document.

/ Jonas

Received on Tuesday, 17 June 2008 22:38:36 UTC