Cart
[Home] [By Thread] [By Date] [Recent Entries]
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
|
