[XML-DEV Mailing List Archive Home] [By Thread] [By Date] [Recent Entries] [Reply To This Message] Re: SAXException, checked, buy why?
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
|
PURCHASE STYLUS STUDIO ONLINE TODAY!Purchasing Stylus Studio from our online shop is Easy, Secure and Value Priced! Download The World's Best XML IDE!Accelerate XML development with our award-winning XML IDE - Download a free trial today! Subscribe in XML format
|