Re: responseXML/responseText exceptions and parseError

Zhenbin Xu wrote:
> Inline...
> 
>> -----Original Message-----
>> From: Jonas Sicking [mailto:jonas@sicking.cc]
>> Sent: Tuesday, June 17, 2008 3:37 PM
>> To: Anne van Kesteren
>> Cc: Zhenbin Xu; Sunava Dutta; IE8 Core AJAX SWAT Team; public-
>> webapps@w3.org
>> Subject: 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.
>>
> 
> [Zhenbin Xu] Regardless what different browser does today, rich parsing
> error is an important feature for developers. I have found it can pinpoint
> the exact problem that otherwise would have been difficult to identify when
> I sent incorrectly constructed XML file.
> 
> And given that the goals is to define a useful spec for future
> XHR implementations, we should define how rich parser error is
> surfaced instead of omitting it because nobody but IE supported it.
> 
> It is even more important we define it in the XHR spec because it is not
> part of DOM Core. Otherwise such a key piece would be lost and we will
> have diverging implementations.

The goal of XHR Level 1 was to get interoperability on the feature set 
that exists across the major implementations of XHR today, so I don't 
think parse error information fits the bill there, but it sounds like a 
great feature to look into for XHR Level 2.

>>> 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
> 
> [Zhenbin Xu] IE does returns an empty document. responseXML.documentElement
> is null but responseXML is not null.
> 
> A typical readyState handler can be written this way:
> 
>         xhr.onreadystatechange = function()
>         {
>                 if (this.readyState == 4 && this.status == 200)
>                 {
>                         var x = this.responseXML;
>                         if (x.parseError.errorCode != 0)
>                         {
>                                 alert(x.parseError.reason);
>                                 return;
>                         }
>                         alert(x.documentElement);
>                 }
>         }
> 
> I don't see why this is not friendly.  It is more comprehensive and gives
> more information than a simple null check, which contains no information
> about what exactly is the parsing error (e.g. which open tag doesn’t match
> which end tag, etc.).

Won't that throw when XHR.responseXML is null, such as when the 
mime-type is something completely different from an XML document?

But I absolutely agree that a null check does not give enough error 
information to usefully do debugging. I was merely saying that a null 
check should be enough to check for if parsing succeeded. The above is 
probably not what you would want to do on an end user site since a user 
won't care which end tag was not properly nested.

/ Jonas

Received on Thursday, 19 June 2008 08:25:43 UTC