OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

 


 

   Re: (NXP)/Java/XML parser : Passing Error Information

[ Lists Home | Date Index | Thread Index ]
  • From: Derek Denny-Brown <ddb@criinc.com>
  • To: xml-dev@ic.ac.uk
  • 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
> 
>1.) Warnings  
>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
event model.)

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.

-derek
--------------------------------------------------------------
ddb@criinc.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 majordomo@ic.ac.uk the following message;
unsubscribe xml-dev
List coordinator, Henry Rzepa (rzepa@ic.ac.uk)





 

News | XML in Industry | Calendar | XML Registry
Marketplace | Resources | MyXML.org | Sponsors | Privacy Statement

Copyright 2001 XML.org. This site is hosted by OASIS