Cart
[Home] [By Thread] [By Date] [Recent Entries]
On Thu, 13 Jan 2005 10:27:37 -0500, Alan Gutierrez <alan-xml-dev@e...> wrote: > * Peter Hunsberger <peter.hunsberger@g...> [2005-01-12 11:05]: > > On Sun, 9 Jan 2005 03:09:45 -0500, Alan Gutierrez > > <alan-xml-dev@e...> wrote: <snip/> > > Later in this message (I'm working backwards) I come to the > conclusion that IoC isn't at play. It's a more general problem > of error handling within an observer pattern. Yes, I agree, you current structure doesn't seem to have an IOC pattern. It's not clear that you need it, but I think what I'm suggesting would enable it if you did want it... <snip>Event/Message discussion</snip> > > > > > > > In any case, this last post isn't so much about Errors, as it is > > > about using SAX to drive Java in ala IoC. > > > The whole idea of how to use IOC for how to handle Errors in a > > framework seems a little murky; from this discussion it almost seems > > like you need some meta-IOC pattern: IOC is driven through > > configuration, configuration itself can result in errors, thus Error > > handling is forced to become a primitive concept, but in your case you > > also want it to be a high level concept. You need a try/catch > > framework around your framework. As such, having testable components > > that case the exterior framework to be invoked in the same way as > > otherwise unhandable primitive exceptions seems the way to go: > > Is IoC really what I'm doing here? No, I don't think so, not yet :-).... > Although "don't call us, we'll call you" is in play here, I > don't think I'm developing something as abstract as > PicoContainer. It's more like Swing. Construction errors are > caught at compile time. You can't addActionListener(new File()); > > > BlowUpNowException for low level errors that indicate the whole > > framework is out of wack. > > Again, compile. > > I'm not using IoC then, because there not configuration, > reflection complexity (yet). The errors that I'm looking to > process are occuring during processing. That can still have an IOC pattern: configuration of the message handler itself. > The framework might still be totally out of wack, for some > Strategy composition. There are programming errors, composition > errors, that could only be detected once a particular branch was > followed. That should be unrecoverable, since it is programming > error and ought to fail fast. > > In the end the options will be ignore, raise, or retry. Until > someone makes that decision, the error message keeps getting > shuffled about. > > > ErrorMessage (ErrorEvent?) throws BlowUpNow (and variations) for some > > configurable instance of a test for transport of Errors that may or > > may not be handled by some specific tester. (Allows orthogonal error > > mangement: degrees of error handled across degrees of error > > tolerance). > > I'm not sure I understand this last bit. What does it mean? "for > some configurable instance of a test for transport"? Basically, you can configure a message to have some level of extra annotation: ignorable info, retriable stuff, warning info, severe error info, or whatever. You can also then configure the message on how to interact with the rest of the framework for one of these annotations: thowable list = warning, error, severe. Throwable handler = ClassX, etc. (maybe just the latter if you don't need to mix and match). Finally, you can then test for existence of one of the message annotations: testForThrowable(), or testForMessageType( MessageType x ) at which point the Message walks the annotations looking for appropriate instances and if it finds it it takes the configured action. The annotations are inserted as they occur. The handling of them is configured according to the Strategy in place. The actual handling is invoked by the various framework components as needed: no annotations matching a given handler, nothing changes. Alternately, retryable found with retry handler in place, away we go to dump the retryable messages to the handler, etc (a message can refer to other messages in this scenario). -- Peter Hunsberger
|
