[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

[PATCH] Include offending XML in "Malformed XML" error message

From: Charles Bailey <bailey.charles_at_gmail.com>
Date: 2005-02-23 20:03:14 CET

Attached is a patchlet that, when expat fails to parse an hunk of XML,
appends at least part of the offending hunk to the error message. It
provides a better jumping-off point for further debugging than the
current message, especially since the line number often isn't all that
meaningful. It's not intended to flag the error specifically, or even
to insure it's actually in the output fragment, since it'd be too hard
to reliably identify the problem. (For that matter, I can envision
cases where the error is actually in a previously parsed hunk of XML,
but doesn't become apparent until a tag mismatches in the current hunk
or the like.) By way of example, the current error message:

   svn: Malformed XML: not well-formed (invalid token) at line 5810


    svn: Malformed XML: not well-formed (invalid token) at line 3; XML starts:

(I've expanded the BS to "^H" for legibility in this message; the
actual error message contains the original text.)

A few comments:

 - The error message now extends over more than one line. I understand that svn
    generally avoids this, but I think it's necessary to supply a
large enough fragment
    that the user can make a well-educated guess about the location of
the problem.
    The presence of \ns in svn-generated XML would also make it tough
to guarantee
    that any meaningful fragment stayed on one line. Finally, trying
to flatten the XML to
    fit on a single logical line would go well past 80 cols, which I
think would be more of a
    problem than multiple lines that fit into an 80 column display.

 - I chose a maximum fragment length of 240 chars arbitrarily, as long
enough to give the
   reader some context and short enough to avoid a huge trail of text.
 It seemed like a
   reasonable balance to me.

 - I placed delimiters before and after the XML with the thought that
it might help in some
   situations where the XML itself started with odd characters; again,
this is relatively
   arbitrary. It'd arguably be of some help for parsing the error
(the delimiters aren't
   legal XML), but as this is a fatal and (one hopes) uncommon error,
I don't think many
   people will be writing tools to anticipate it. If the consensus is
that they just add noise,
   they're easy enough to drop.

Patched HEAD builds clean here, of course, and passes all but three of
the regression tests, none of which appear related to this patch.

'Nuff said about a minor patch for an infrequent occurrence. Chalk it
up to it being my first foray onto this list.

Charles Bailey
Lists: bailey _dot_ charles _at_ gmail _dot_ com
Other: bailey _at_ newman _dot_ upenn _dot_ edu

To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org

Received on Wed Feb 23 20:04:18 2005

This is an archived mail posted to the Subversion Dev mailing list.

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.