Re: [xml-dev] Observer Pattern and Errors (Was: SAX IoC Errors)

[Peter Hunsberger <peter.hunsberger@gmail.com>]

On Thu, 13 Jan 2005 10:27:37 -0500, Alan Gutierrez
<alan-xml-dev@engrm.com> wrote:
> * Peter Hunsberger <peter.hunsberger@gmail.com> [2005-01-12 11:05]:
> > On Sun, 9 Jan 2005 03:09:45 -0500, Alan Gutierrez
> > <alan-xml-dev@engrm.com> 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