Message handlers and error handling

[Tom Zeller]

> The earliest failures I run into in the flows are usually message handler
> exceptions, unsurprisingly, and this triggers a question: what should I do
> to map exceptions from different handlers into useful events?

Like

 event = EventResolver.lookup(String eventID)

or

 event = EventLookupStrategy.apply(BaseContext SomeContext)

?

> For example, SP authentication failures should eventually map back to
> REQUEST_DENIED status codes in some cases, but I don't have that detail
> because the handlers aren't event aware (or profile action aware at all).
>
> I had to trap the exception being thrown by the adaptor that turns handler
> chains into profile action beans because Web Flow really is clear that it
> doesn't want you to use exceptions as transitions. Which is good, because
> I don't either, and we basically stopped using that model (*).

<nods>

> But that doesn't give me a useful Event to signal back. I think we have to
> do something more profile-aware with the MessageHandlers. A simple
> suggestion would be to inject an event ID as a property of the handler
> applying to all exceptions it raises. That's not flexible, but handles a
> decent set of cases.

Maybe inject a map instead of a String ?

 handler.setExceptionToEventIDMap(Map<Exception, String> exceptionToEventIDMap)

> I guess another option is to actually set an EventContext on the
> MessageContext and pick that up in the bean adaptor and move it over to
> the profile context. That's a bigger code change obviously, but is the
> most explicit fix.

I think everything I just typed is wrong because I was thinking we had
an Event in java-support which abstracted the SWF Event, and I was
reading this as that class and not Spring's.

> We just have two different signaling models in the code and I think we
> need fewer.

I don't know exactly what you mean by signaling, but I think that
having Handlers and Actions the way we do now might be undesireable in
the long run. Probably a different thread, but that is what comes to
mind.

> (*) So much so that I'd suggest we consider dumping the ProfileException
> from the execute() signature on the actions. We can't do anything useful
> with it and I've almost universally avoided ever using it. Possibly
> totally, I haven't checked.

With looking, sounds good. The only condition I can think of right now
to trigger a ProfileException being thrown during execute() is if a
bug exists in pre-execute() because of a missing "test", but I am not
sure that is correct.

I hope any of this makes sense.