Re: [Boost-users] [MSM] state transitions and exceptions

3 Apr 2012


      Hi Stephan,
...
On Thu, Mar 29, 2012 at 9:46 PM, Christophe Henry
 wrote:
...
First of all, I have to give a word of caution. The UML Standard does not
foresee exceptions and they don't mix well with the run-to-completion
algorithm on which state machines rely. Try to avoid them if you can.
Yes, mum.   ;-)
I know, it's quite a pain and I have to deal with that quite often.
Doing UML interface descriptions in common tools expose this
particular problem all the time. In my opinion however, it is a
problem the UML Standard has, not me. *duck*
I agree. Such a big Standard and so many holes...
...
...
Like the no_transition handler, you can overwrite it with your own.
When this is called, the transition is interrupted where it was and 
ceases
processing. This leaves you in a not very desirable state because you 
have
been interrupted somewhere in the guard/exit/action/entry chain.
When this happens, I advise you to process to yourself an error event to
handle this gracefully. For example:
template 
void exception_caught (Event const&,FSM& fsm,std::exception& )
{
fsm.process_event(ErrorConnection());
}
Yes, that can work. I wasn't aware I can post events from within the
state machine. But they are actually queued, as I see. Nice. It's
getting even better. This should be able to deal with the problem.
Only downside I can see is that I'd need an entry in the transition
table for each state. I already had to adjust those MPL settings. But
this will work, thanks.
Or you can use a second region NoError --> Error. This costs you only 1 
transition and it is in the spirit of the Standard.
With a msm flag marking Error, you know when your fsm is in error mode.
...
...
You can prevent MSM from catching the exception by activating in your 
front
end a switch:
typedef int no_exception_thrown;
Then, you get the exception thrown from your process_event call.
I think your first solution ist better because it allows me better to
reset internal data to reasonable values.
...
In any case, the transition where the exception occurs is terminated and 
you
don't need to terminate yourself.
OK, thanks. This should be explicitly stated like that in the
tutorial. Or maybe it is and I just couldn't find it. Maybe there's
room for one of those little chapters titled "exceptions".
Should be possible, yes ;-)
...
On a side note, there also could be room for a few words about how do
I position such a thing in an existing (or new) architecture. Like
best or common practice. When I started to work with it I was entirely
unsure about it. I am here in a MVC arch with basically a GUI and a
backend and threaded multiplexing controller (part of the GUI) ->
backend functions and demultiplexing data signals -> GUI changes. As a
first try, I understood the state machine as part of the controller
logic belonging to one functionality and essentially one widget. Which
meant that the SM was posting events to the backend functions in a
threaded Q. This proved no good as the result of this was that a state
could easily be switched without the backend having reacted yet,
creating races and the possibility of acting twice. So I have moved it
back behind the multiplexing, not posting async and so far I think I'm
far better off. Another issue were interactions with other parts of
the applications that send signals about, interfering with things the
SM is now concerned with. Effectively creating need for far more reach
the SM needs to have. Stuff like that. Christophe, if you are
interested, I may be able to churn out a little article and about that
if you are interested.
I surely am interested as I plan a few papers or tutorials on this matter. 
msm used with asio, or as the Controller part of a MVC.
Another point of view cannot hurt.

Cheers,
Christophe