Subflow error management and return values.

[fuad]

Hi guys!

How should I handle errors in subflows? Let say I catch exception during executing the action in subflow. Should I explicitly define transition to the end-state on="error" in this action state or it is just enough to throw error event without showing transition?

Here are some snippets. In main flow:

<subflow-state flow="tools.DoSearch" id="tools.DoSearch">
	<attribute-mapper bean="searchType.attributeMapper"/>
	<transition to="selectSearch.view" on="finish"/>
	<transition to="error" on="error"/>
</subflow-state>

and in subflow:

<action-state id="retrieveAction">
	<action autowire="byType" method="retrieveStudiesFromArchive" class="StudyAction"/>
	<transition to="overview" on="success"/>
	<transition to="finish" on="error"/>
</action-state>

...

<end-state id="finish"/>

In code above I have transition to the end-state on error during action execution in subflow, and in definition of subflow I have transition to the error page if subflow execution finished with error. Is it right or I miss something?

Additionally, I read in docs that subflows can return values. Could you please give some more info about it and some examples?

Thanks a lot in advance.

Cheers,
Fuad

[Keith Donald]

You need to make a distinction between recoverable errors and unrecoverable errors. For unrecoverable errors, let the exception throw up the callstack, to be handled by whatever client dispatched the request (e.g the Spring MVC DispatcherServlet, who will typically map the exception to a error page.) For recoverable errors, catch the exception in your action code and signal an appropriate error event so your flow can respond to it. By respond, I mean the flow will map the event to an appropriate state transition.

I think I see one problem with your code snippets:

- The parent flow that is spawning "tools.DoSearch" as a subflow defines end event mappings for "finish" and "error." This is all fine. However, the transition in the subflow's "retrieveAction" state for the "error" event is the "finish" end state. This means the parent flow will see the "finish" end result and map to the "selectSearch.view" state, instead of seeing the "error" result, and responding to it. This is presumably not what you want.

So as you see, the subflow signals an ending event with the ID of the end state that is entered. This is how the subflow influences the next state to transition to in the parent, when the subflow ends and the parent resumes. You can think of it as the the parent flow responding to the ending result of the subflow.

Regarding attribute mapping - I presume you've already configured input mappings using the ParameterizableAttributeMapper, which pass attributes in a parent flow down to a spawning subflow. Similiarily, you can configure output mappings to do the reverse: that is, pass attributes of an ending subflow up to a resuming parent flow.

HTH,
Keith

[fuad]

Hi Keith,

Thanks a lot for your response. I got what I missed. I have to add error end-state and make transition on error to that end state in "retrieveAction". Like I would do it for any kind of end-state to give parent flow information to respond accordingly.

You need to make a distinction between recoverable errors and unrecoverable errors. For unrecoverable errors, let the exception throw up the callstack, to be handled by whatever client dispatched the request (e.g the Spring MVC DispatcherServlet, who will typically map the exception to a error page.) For recoverable errors, catch the exception in your action code and signal an appropriate error event so your flow can respond to it. By respond, I mean the flow will map the event to an appropriate state transition.

Is there any need to make some clean up if exception is thrown? For example continuations will be somewhere in map. What will happen with parent flow state when exception is thrown in sub-flow?

Cheers,
Fuad.

[Keith Donald]

If an exception is thrown up the stack and caught by the dispatcher servlet and routed to a error page, the flow execution by default will continue to sit around in the session until the session expires; that is, if you are choosing to persist your flows in the session. The same applies if I start a flow and then go to the bathroom and don't come back for awhile.

With that said, there is a ExpiredFlowCleanupFilter you can install that will automatically detect and cleanup expired/abandoned flows. See the web.xml file of the ItemList sample, which illustrates this.

Also, if you're using a client-continuation based flow execution storage strategy, no cleanup is neccessary as there is no session state.

On the other hand, If you're using a http session continuation based flow execution storage strategy (sellitem does this by default), a new copy of the flow execution is created and stored in the session on each flow request. This is the most expensive strategy in terms of storage, but the most flexible with regards to state restoration (e.g allowing proper back button use--as you can restore the flow at any point from a unique, cached flowExecutionId in local history.)

So of the three flow execution storage strategies, the default "session" requires some storage, but not as much as the "continuations-based session" strategy. In those cases, the ExpiredFlowCleanupFilter can help for abandonded/errored out flows, as normal flows that reach a end state will always be cleaned up automatically. The client strategy requires no session state at all, but has some other tradeoffs (e.g security issues, limitations with GET)

[fuad]

Thanks a lot, Keith.

Fuad.

[durdina]

For recoverable errors, catch the exception in your action code and signal an appropriate error event so your flow can respond to it. By respond, I mean the flow will map the event to an appropriate state transition.

Hi,
I am suggesting another way of handling recoverable/checked exceptions:
http://sourceforge.net/mailarchive/m...sg_id=11479934

The solution lies in declaring checked exceptions in the flow configuration and declaring mapping that maps typed exceptions to appropriate events. All exception handling then would be only a way of flow configuration and it would take away the burden from developer to do the same exception handling in every action of the controller.

What do you think about this feature?
Thank you, Michal