Alan Gutierrez wrote:
> * Karl Waclawek <karl@w...> [2005-01-04 19:30]:
> 
>>
>>Alan Gutierrez wrote:
>>
>>
>>>   If the sender and receiver agree on a class, then they can put
>>>   it in variables map attached to the StrategyError.
>>
>>What about behaviour?
> 
> 
>     Thanks. Yes.
>     
>  ~A On data.
>  
>     I think this is something of a common problem with frameworks.
>     It feels counter intuitive to say that the signature for an
>     event is as simple as.
> 
>     public interface Event {
>         public int getType();
>         public Object getData();
>     }
> 
>     But, what more can the conduit designer know about a particular
>     event? Especially something as generic as an "error" event.

One should not try to make too many assumptions.

>     It seems silly, to me, to have an interface like so:
> 
>     public interface ErrorData {
>     }
> 
>     public interface Error {
>         public ErrorData getErrorData();
>     }
> 
>     This is a common problem I see arrising in frameworks. You want
>     to be extensiable, so you have to forgo some typing, or else use
>     reflection, which also forgos typing.

Or you allow types to be constrained later.
Generics could be a way to achieve that.
Tried it in .NET 2.0. Opens new possibilities.

> 
>     That's why I suggested a map. It seems like after I've worked
>     with this error handler long enough, I'd know what sort of
>     typing to add and how.

> 
>   ? What processing specific data is available.
> 
>     What other data occurs in an error? Do I want to provide a path?
>     A smidge of overhead, and already part of my system. But, if
>     from another SAX filter, that path might not have a real
>     document to reference. 
> 
>     Document location. Again, might not exist, since these might
>     only be events. Imagine a SAX handler that simply watches a socket.
>     Still, good candidate.
> 
>     For SAX Strategy, my library, the current strategy, and the
>     current event (because I create event objects to encasualte
>     event data).

Again, leave it to error producer and consumer.
The API does not have to know.

>  ~B On behavior.
> 
>     That's hard. What behavior is common to all error handling?
>     
>     I'd like to know, really, because I'd like to take some time to
>     develop some error handling best practices, and perhaps, and
>     error event library is a project in itself.

Rolling back to a previous consistent state, then
retry, maybe with a different code path.
Or logging, displaying a message,...

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.

Karl