[
Lists Home |
Date Index |
Thread Index
]
* Karl Waclawek <karl@waclawek.net> [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.
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.
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).
~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.
Uche, in a other thread, broke down handling, as pass, fail,
log, or fix. For pass, fail/raise, and log, one can probably
provide default implmentations, and dispatch them based on
pattern matching.
This exception class, raised by this handler, log and fail.
Oh, I guess, with an interface as simple as this.
public interface StrategyCassandra {
public void error(StrategyError strategyError);
}
At some point I was expecting to see the fixes written out in
the error method, so the interface name is now a misnomer.
The object will not always be a Cassandra.
public interface ErrorResponder {
public void error(Event event, StrategyError error);
}
Then you get this implementation, which oddly takes the place of
a catch block.
public class ErrorDispatcher implements ErrorResponder {
public void forError(ErrorResponder response);
public void forError(Class exceptionType, ErrorRepsonder response);
public void forErrors(Class[] exceptionTypes, ErrorRepsonder response);
}
The error method could return boolean, and that is checked to
see if the error was handled. Or maybe the StrategyError has a
retry method.
public void parseFooXML throws SAXException {
ErrorDispatcher dispatch = new ErrorDispatcher();
dispatch.forError(FileNotFoundException.class, new ErrorResponder() {
public void error(Event event, StrategyError error) {
String fileName = event.getElement()
.getAttributes()
.getValue("file-name");
if (!creatyPlaceHolderFooXML(fileName)) {
throw strategyError;
} else {
strategyError.retry();
}
}
});
dispatch.forError(FooResourceException.class, new ErrorResponder() {
public void error(Event event, StrategyError error) {
throw BarFooResourceError();
}
});
XMLReader reader = new XMLReaderFactory.createXMLReader();
EventSink eventSink = new StrategyChain()
.strategy(new FooStrategy())
.newEventSink(dispatch);
reader.setContentHandler(eventSink);
boolean processed = false;
do {
try {
reader.parse(new InputSource(new FileInputStream("foo.xml"));
processed = true;
} catch (FooBarResourceException e) {
if (!FooResourceManager.freeUpSomeFoos()) {
throw e.getCause();
}
}
} while (!processed);
}
Better?
--
Alan Gutierrez - alan@engrm.com
- References:
- Re: [xml-dev] SAXException, checked, buy why?
- From: Alan Gutierrez <alan-xml-dev@engrm.com>
- Re: [xml-dev] SAXException, checked, buy why?
- From: Karl Waclawek <karl@waclawek.net>
- Re: [xml-dev] SAXException, checked, buy why?
- From: Alan Gutierrez <alan-xml-dev@engrm.com>
- Re: [xml-dev] SAXException, checked, buy why?
- From: Karl Waclawek <karl@waclawek.net>
- Re: [xml-dev] SAXException, checked, buy why?
- From: Alan Gutierrez <alan-xml-dev@engrm.com>
- Re: [xml-dev] SAXException, checked, buy why?
- From: Karl Waclawek <karl@waclawek.net>
- Re: [xml-dev] SAXException, checked, buy why?
- From: Alan Gutierrez <alan-xml-dev@engrm.com>
- Re: [xml-dev] SAXException, checked, buy why?
- From: Karl Waclawek <karl@waclawek.net>
- Re: [xml-dev] SAXException, checked, buy why?
- From: Alan Gutierrez <alan-xml-dev@engrm.com>
- Re: [xml-dev] SAXException, checked, buy why?
- From: Karl Waclawek <karl@waclawek.net>
|