Lists Home |
Date Index |
- From: Derek Denny-Brown <email@example.com>
- To: firstname.lastname@example.org
- Date: Wed, 04 Jun 1997 13:29:38 -0700
At 05:02 PM 6/4/97 +0200, Norbert Mikula wrote:
>To my understanding there are several classes
>of errors that can be passed along
>2.) WF violations
>3.) Violations with respect to the DTD
>4.) In general these errors that are reportable - if the user wishes
>Should they be handled differently ?
>I was thinking in terms of "callback" functions. Like
>I do it right now with the "Esis" interface.
I would tend to agree that a callback mechanism would be the most useful
way to accomplish error handling. I strongly believe that it should be
possible to break up error messages into different types, with all the
necessary information for a application to process the error itself (and
build it's own error message, open an editor to the correct file &
character in that file, etc). It should be easy for an application to
ignore certain types of error messages (or, reverse that, it should be easy
to only pay attention to the ones it cares about).
Not having looked at NXP's code, I am not sure how it's current ESIS
interface works, but this is also a reasonable application of inheritance.
There might be a general HandleError() method, which (by default) is just
a multiplexor to call separate methods for each type of error. This is
akin to the AWT 1.0 event model. Alternatively you could have a more
callback-like (AWT 1.1 like) model, which would be marginally more
difficult to code (for Norbert) but is slightly more elegant. From my
point of view it is an even call, since both work and neither is
particularly horrid. (Most of the issues for why the AWT event model was
changed do not apply here since this is a very specific case, not a general
My main interest, with regard to what I would like in any parser I would
use, would be a clean mechanism to be able to handle errors in an
application specific way. This is more than just, 'where do I print the
error message?' and includes the ability to write an editor application
which could use the parser to validate and then jump directly to the
line/character of any errors. SP goes a ways toward that, but I would
prefer a hierarchy of errors, similar to some of the object oriented event
models that I have seen recently.
email@example.com || software-engineer || www/sgml/java/perl/etc.
"Just go that way, really fast. When something gets
in your way, turn." -- _Better_Off_Dead_
xml-dev: A list for W3C XML Developers
Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/
To unsubscribe, send to firstname.lastname@example.org the following message;
List coordinator, Henry Rzepa (email@example.com)