Design: Xerces Error Reports & Handling

[James Berry <jb...@criticalpath.com>]

Some time ago there was discussion of adding additional facilities to Xerces
to make error detection easier for the simple usage cases. I did some work
on this a while back, but haven't submitted the changes. Before I do so, I
thought I'd write up my changes and request feedback.

I think there are three basic usage patterns for Xerces that require
error handling:

 (1) Very simple: "just parse this, give me the data, and
     let me know if it failed".
 (2) Moderate: "parse this, give me the data, and let me
     know in brief how it failed".
 (3) Complex: "parse this, give me the data, and give me
     details on all the ways in which it failed.

Which degree of error handling is required depends on the particular
application for Xerces.

In designing the "std" error reporter and error report, I'm trying to
address the first two, but not the last (which will require a custom
error handler).

I've created two new classes, XMLStdErrorReporter and
XMLStdErrorReport. The reporter derives from the ErrorHandler, and the
error report derives from XMLException.

To handle these two cases, the XMLStdErrorReporter has an ability to
throw an exception (XMLStdErrorReport) and/or print details of the
error to stdio. Each of these is configurable by level of importance
(report nothing, report fatal, report errors, report warnings, report all).

The XMLStdErrorReport bundles the data as reported in the error
handler (as a SAXException) and converts it over into an
XMLException. I chose the XMLException hierarchy here, rather than
SAXException, due to the fact that the parsers already report
XMLExceptions in other places, so a DOM client would thus need only to
catch XMLExceptions, probably.

These classes, in conjunction with a simple change to allow the
parsers to return an error indication or error count, therefore
provide for the first two usage scenarios as follows:

 (1) Setup the std error reporter to not throw an exception
     and to log to stderr if desired. Determine outcome of
     parse by examining result from the parser. Be prepared
     to handle an exception anyway, since they are thrown in
     other cases by the parser.

 (2) Tell std error reporter to throw the exception and to
     log if desired. Determine outcome of parse by either
     examining the result from the parser or by watching
     for the exception. The exception, if it comes, will
     contain all known information about the error (at least
     as much as the error handler reported).

I think these are the two most common scenarios, and the third is too
broad to predict or design for. Note that in these cases, therefore,
it is no longer necessary to create a custom error handler, the "std"
error handler can be used.

Following that far too long explanation, my questions are:

 (a) General comments?

 (b) Where should the files live in Xerces? ErrorHandler is in
     sax/, XMLException is in util/. These classes would kind of
     seem to want to live together. Either in framework or in
     util? Philosophy? Or has the organization degraded too far
     to make any answer obvious?

 (c) The stdio logging feature is kind of gratuitous in that
     there are no good answers for what logging mechanism to
     use. We don't have any standardized logging support in
     the x-platform space. I guess stdio at least helps to
     support the sample programs: if someone wants to do
     more (or different) they can just catch the exception and
     report the stuff however they want. Any other thoughts?

 (d) I need to allocate new XMLExepts codes (and strings) for
     the new exceptions. The header at the top of
     XMLExceptMsgs.h says it's machine generated. Who/where
     should I go to get new codes allocated? I must be missing
     something, but it's not obvious to me where these come
     from.

 (e) I've added an int result to the DOMParser::parse method
     which returns the number of errors encountered. This is the
     "simplest" means of detecting an error. I'd like to do
     the same for the SAX parser, but it's part of a more
     involved class hierarchy and will tend to be overridden
     anyway; any change I make will ripple through the code of
     all SAX clients. My inclination is to not change the void
     result from SAX parse: anybody else?

I'd be pleased with any feedback. In the absence of such I'll make my own
choices. Actually, though, I'd love and answer at least on (d).

-jdb

-- 
/**********************************
 James D. Berry
 mailto:jberry@criticalpath.com
 vox:503.265.1213 fax:503.222.3020
 **********************************/

Re: Design: Xerces Error Reports & Handling

[James Berry <jb...@criticalpath.com>]

Thanks Dean. I've always managed to avoid that directory ;)

-jdb

On 10/24/00 7:12 PM, "Dean Roddey" <dr...@charmedquark.com> wrote:

>>  (d) I need to allocate new XMLExepts codes (and strings) for
>>      the new exceptions. The header at the top of
>>      XMLExceptMsgs.h says it's machine generated. Who/where
>>      should I go to get new codes allocated? I must be missing
>>      something, but it's not obvious to me where these come
>>      from.
>> 
> 
> Look in the src/nls/ directory. There is an XML file which contains the
> errors. Look in tools/nls/Xlat for the code for the tool that digests that
> XML file and spits out the various formats required for the message loaders
> supported by the parser.
> 
> --------------------------
> Dean Roddey
> The CIDLib C++ Frameworks
> Charmed Quark Software
> droddey@charmedquark.com
> http://www.charmedquark.com
> 
> "It takes two buttocks to make friction"
>   - African Proverb
> 
> 
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: xerces-c-dev-unsubscribe@xml.apache.org
> For additional commands, e-mail: xerces-c-dev-help@xml.apache.org
> 
> 

Re: Design: Xerces Error Reports & Handling

[Dean Roddey <dr...@charmedquark.com>]

>  (d) I need to allocate new XMLExepts codes (and strings) for
>      the new exceptions. The header at the top of
>      XMLExceptMsgs.h says it's machine generated. Who/where
>      should I go to get new codes allocated? I must be missing
>      something, but it's not obvious to me where these come
>      from.
>

Look in the src/nls/ directory. There is an XML file which contains the
errors. Look in tools/nls/Xlat for the code for the tool that digests that
XML file and spits out the various formats required for the message loaders
supported by the parser.

--------------------------
Dean Roddey
The CIDLib C++ Frameworks
Charmed Quark Software
droddey@charmedquark.com
http://www.charmedquark.com

"It takes two buttocks to make friction"
    - African Proverb