[XML-DEV Mailing List Archive Home] [By Thread] [By Date] [Recent Entries] [Reply To This Message]

Re: Error and Fatal Error

• From: Peter Flynn <peter@silmaril.ie>
• To: xml-dev@lists.xml.org
• Date: Mon, 18 Jul 2011 00:13:51 +0100

On 17/07/11 12:10, Stephen D Green wrote:
> Thanks Mukul for these relevant qutes from the spec.�
> �
> "errors and MAY report such errors to the application."
> �
> so far so good.
> But the next�two sentences, to someone like myself trying to interpret the
> spec, look like they are contradictory. (Perhaps the reason parsers
> seem to have a gap in their usability logic.)
> �
> "In order to
> support correction of errors, the processor MAY make unprocessed data
> from the document (with intermingled character data and markup)
> available to the application."

That means that if the parser encounters some garbage like

<para>Thanks Mukul for these relevant qutes from the spec.</para>
<<<<<<quote>errors and MAY report such errors to the application.</quote>

then when it reports the second < in the second line as not being a 
name-start character, it is allowed to read on a little bit (with the 
parsing turned off!) so that the application can quote the line and its 
context to the user so they can identify where the error is. This is 
regarded as better than error messages like
ERR 32786 REDO FROM START

> "Once a fatal error is detected, however,
> the processor MUST NOT continue normal processing (i.e., it MUST NOT
> continue to pass character data and information about the document's
> logical structure to the application in the normal way)."
> �
> If the app MUST NOT continue normal processing, how can it properly
> "make unprocessed data
> from the document (with intermingled character data and markup)
> available to the application" [to support the correction of errors]

Precisely as I have described above. It can read on a little bit in 
plain-text mode, in order to capture some context.

> It seems to me (and it seems plainly stated to this effect in the
> manual/instructions accompanying the parser I use) that once the
> exception is thrown there is no guarantee what state the parser
> will be in -

That is exactly the problem with errors in XML, and exactly why a parser 
must not continue to deliver something masquerading as a parsed 
structure, when there is no way any more to guarantee that that was the 
structure encountered.

> and therefore it seems an unreliable point from which
> a developer's code can start to correct the error in the markup.

I believe you have finally answered your original question yourself.

///Peter

• References:
  • Error and Fatal Error
    • From: Joe Fawcett <joefawcett@hotmail.com>
  • Re: Error and Fatal Error
    • From: Mukul Gandhi <gandhi.mukul@gmail.com>
  • Re: Error and Fatal Error
    • From: Stephen D Green <stephen.green@documentengineeringservices.com>