RE: responseXML/responseText exceptions and parseError


> -----Original Message-----
> From: Jonas Sicking [mailto:jonas@sicking.cc]
> Sent: Thursday, June 19, 2008 1:24 AM
> To: Zhenbin Xu
> Cc: Anne van Kesteren; Sunava Dutta; IE8 Core AJAX SWAT Team; public-
> webapps@w3.org
> Subject: 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.
>


[Zhenbin Xu]




> >>> 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


[Zhenbin Xu] The way it was designed is that responseXML is always not null once
it is in OPENED state.  I don't think IE currently give out rich error information
about mimetype mismatch but the design allows it to be exposed on responseXML, if
necessary.

It is still prudent to do the above check on end user site because it is more
robust against server error or corrupted data.  Certainly in such cases
the error handling path should do something more user friendly and sensible than
mere alert.

Received on Thursday, 19 June 2008 20:58:35 UTC