RE: responseXML/responseText exceptions and parseError

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.




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

Received on Thursday, 19 June 2008 01:11:06 UTC