Message handlers and error handling

[Cantor, Scott]

On 4/15/14, 1:03 AM, "Tom Zeller" <tzeller at dragonacea.biz> wrote:

>> 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)

No. I don't have an event at all, just a generic MessageHandler exception.


>Maybe inject a map instead of a String ?
>
> handler.setExceptionToEventIDMap(Map<Exception, String>
>exceptionToEventIDMap)

We don't have anything but one exception type in the handlers, so there's
nothing to map. And I don't really want to create a big exception
hierarchy either.

>>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,

Error signaling. The MessageHandler invoke() method returns void and
signals anything it needs to be using an Exception. Actions return an
Event from execute() either directly or by attaching it to an EventContext
in the tree, and rarely if ever throw.

>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 don't throw them in preExecute either, but if I did it would propagate
out, yes. I'm really suggesting just dumping that capability and treating
exceptions from Actions as a rare, fatal occurrence and let it be handled
by an MVC-mapped exception handler, same as if we have a Spring exception
like a bad web flow definition.

This is what seems to be strongly implied by the SWF Action interface docs
as the expected way to do it. You throw if it's a catastrophe you can't
recover from, not as a logic signal.

-- Scott