Alan Gutierrez wrote:
> * Karl Waclawek <> [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
