* Karl Waclawek <karl@w...> [2005-01-05 00:47]:
> 
> 
> Alan Gutierrez wrote:
> >* Karl Waclawek <karl@w...> [2005-01-04 19:30]:
> >
> >    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.

    Yup. yup. Trying not to get into JDK 1.5 yet, though.

> >    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.

    ?

    Maybe, if I said, in SAX Strategy, the SAX events are
    encapsulated in Event objects, that contain the SAX event data.

    I'm not talking about attempting to encapsulate error event data
    for the producer or consumer.

> > ~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.

    Do you have this sketched out somewhere?

--
Alan Gutierrez - alan@e...