Message handlers and error handling

[Brent Putman]

On 4/15/14 11:46 AM, Cantor, Scott wrote:
> On 4/15/14, 11:41 AM, "Tom Zeller" <tzeller at dragonacea.biz> wrote:
>> As you originally suggested, injecting the Event ID as a property of a
>> handler is fine with me.
> I can live with it (and it's certainly less work), but I suspect we'll run
> into cases where handlers throw exceptions in cases that mean different
> things to the overall flow. But I haven't looked (and certainly handlers
> are meant to be discrete to the point of not doing this).

Yeah, for that reason I'm not particularly keen on the idea of injecting
things into the message handlers that are really about profile handling
logic.  That seems like a bad separation-of-concerns.

Can't we get pretty much the same effect by injecting the event ID into
the adaptor?  That also takes care more cleanly of the
contextual-specificity of the event ID, for example if sometimes an
exception from handler X means different things.

There's obviously an issue if 1) the handler is actually a handler chain
(you don't know from which specific handler the exception came) and 2)
you actually need (in that particular adaptor instance) to differentiate
behavior based on different handlers in the chain.  Re: #2 I'd be
interested to see cases where that was actually true.   Assuming they do
exist:  I think you could easily solve this by dispensing with the
actual handler chain and just having an adaptor for a
List<MessageHandler>.  Then it knows which one it's executing, and you
can have a Map which maps Handler X -> Event E.  Or if we ever do make
use of more strongly typed exceptions in the handlers: (Handler X,
Exception Y) -> Event E.

Or of course you could do something similar along with wrapping each
handler in its own distinct adaptor with an injected event ID.  Possibly
even executed in a subflow.

The MessageHandlerChain was/is a usable abstraction for the library, but
if it doesn't make sense in the context of WebFlow and event-based
handling, then we don't have to use it. It just loops of the
List<MessageHandler>, so there's not much to re-implementing that in way
more useful for WebFlow, etc.


On a completely different note:  I did have some very early plans way,
way back for how error handling would work in a pure
MessageDecoder/-Encoder and MessageHandler environment.  That's the
interfaces in the messaging-api 'error' and 'error.servlet' packages. (I
may be the only one whose even aware of them).  I did have some impls in
my proof-of-concept repo from years ago but none of those made it into
OpenSAML, since back then it wasn't clear where we were going.  Mostly
of historical interest, and maybe not relevant for use in SWF.  But for
example you can probably see where I was going with the pipeline one
that handles an error using an outbound message encoder, to reply to the
responder.  There was also an assumption of the use of a bit more
structured exception handling and exception types than we do today.





-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://shibboleth.net/pipermail/dev/attachments/20140416/9a77f2f2/attachment-0001.html