SAX: Error Reporting (question 4 of 10)

[David Ornstein]

David Megginson <ak117 at freenet.carleton.ca> wrote [09:50 AM 1/3/98 ]:
>Should SAX treat errors as events?  If so, should it distinguish fatal
>errors from warnings or non-fatal errors?

Yes.  Yes.

Details below for those who care...

>There is an important distinction here: warnings are strictly
>informative, and may be useful for debugging, 
[clip]
>Normally, these would go to STDERR or to a log, and people would view
>them only if they were trying to track down a problem.  Fatal errors,
>on the other hand, should ordinarily stop processing and fling
>themselves in the user's face:
[clip]
>Normally, these would throw an error or exception, and the programmer
>might want to display the message in a dialog box.

We should not make decisions a priori for Clients.  Which messages the
Client might or might not want to show to users (or otherwise act on),
should not be pre-determined in the interface.

>CON
>- Java already has throwable errors and exceptions, which provide a
>  more elegant method for error reporting.

But, as far as I know, there are no (good?) cross-language exceptions
handling mechanisms.  How would a C++ or PERL client catch a Java exception?

>PRO
>- some OO languages do not have throwable errors and exceptions; this
>  approach should be simple enough to work with all of them;

Right.

>- there can be default implementations in XmlAppBase, so users can
>  ignore these if they wish.

As mentioned in the thread "do we want a base class," I propose that we not
assume the presence of an XmlAppBase beast when formulating the PRO/CON lists.

>MY RECOMMENDATION
>-----------------
>
>Yes to both.
>
>We can have the following default implementations in XmlAppBase:
[clip]

Good for Clients, not for Implementors, for reasons stated previously.

>FURTHER CONSIDERATIONS
>----------------------
[clip]
>Do we need a 'column' argument as well as a 'line' argument, or is
>'line' enough?  I don't know if all parsers track the current column,
>but we could define a behaviour for those that do not (such as
>reporting the column as -1).

I'd really like to see the column information.  I'd also like to have an
offset from the start of the stream.  Somebody (Tim?  James?) said that
their parser did all three.  I've often needed all of them.

This one isn't a killer, though, and your defined behavior for non
implementors is a fair tradeoff.

David


================================
David Ornstein
Pragmatica, Inc.
http://www.pragmaticainc.com


xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev at ic.ac.uk
Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/
To (un)subscribe, mailto:majordomo at ic.ac.uk the following message;
(un)subscribe xml-dev
To subscribe to the digests, mailto:majordomo at ic.ac.uk the following message;
subscribe xml-dev-digest
List coordinator, Henry Rzepa (mailto:rzepa at ic.ac.uk)