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

 


Help: OASIS Mailing Lists Help | MarkMail Help

 


 

   Re: [xml-dev] SAXException, checked, buy why?

[ Lists Home | Date Index | Thread Index ]

Alan Gutierrez wrote:

>>But again, if the Error class is abstract, one can subclass with
>>appropriate behaviour, known to the producer and consumer, but not
>>the API that just forwards the error.
> 
> 
>     Do you have this sketched out somewhere?

Maybe I am misunderstanding the whole problem, but what
I mean is so simple (in C#):

public abstract class SAXError
{
   // some always useful members
   public abstract Exception GetException();
   public abstract string GetMessage();
}

public interface IErrorHandler
{
   public void Error(SAXError error);
   ...
}

// known to content handler and application
public class MyAppError: SAXError
{
   public override Exception GetException() {...}
   public override string GetMessage() {...}
   // app specific members - data and/or behaviour
   public void Recover() {...}
}

// application level error handler, an instance of which
// is registered with the content handler
public class MyErrorHandler: IErrorHandler
{
   public void Error(SAXError error)
   {
     // type cast that does not throw exception
     MyAppError myError = error as MyAppError;
     if (myError == null) {  // not a MyAppError
       log(error);
       throw error.GetException();
     }
     else {
       myError.Recover();
     }
   }
}

In this case the API (IErrorHandler) has no notion
of MyAppError.Recover().

Karl




 

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

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