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