Re: [boost] [MSM] Is there any interest in C++14 Boost.MSM-eUML like library which compiles up to 60x quicker whilst being a slightly faster too?

Subject: Re: [boost] [MSM] Is there any interest in C++14 Boost.MSM-eUML like library which compiles up to 60x quicker whilst being a slightly faster too?
From: Vicente J. Botet Escriba (vicente.botet_at_[hidden])
Date: 2016-02-05 19:03:24

Le 05/02/2016 22:30, Krzysztof Jusiak a écrit :
> On Fri, Feb 5, 2016 at 5:55 PM, Vicente J. Botet Escriba <
> vicente.botet_at_[hidden]> wrote:
>
>> I have not found anything about how exceptions are managed nor about
>> inheritance of state machines. Is there something related to these two
>> subjects on your library?
>>
>>
> It's a valid point. Documentation was lacking much info about exceptions
> safety. I've just added it here ->
> http://boost-experimental.github.io/msm-lite/overview/index.html#exception-safety
> Currently, there is no much policy about exception handling though.
> However, if guard/action throws state machine will be in a defined state.
> Any problems you have encountered with the exceptions?
I'm not yet to the point to try the library. I'm just reading the doc 
and asking for things I use to use.

Thanks for the pointer.

With the UML2 transition model is harder to manage with exceptions, as 
the next state is on the transition table and the the engine must be 
concerned.

I don't understand clearly the different behavior when exceptions 
escapes a guard or an action. Changing to the next state could call to 
the entry of the state. In any case what you proposes don't allow to 
handle the exception at a higher level.

My preference is to go to an associated catch exception 'pseudo state' 
and request the process of an associated exception event.

I believe that we could add an associated catch pseudo-state

src_st + event [guard] / action = dst_st|catch_st

When there is an exception on this transition the catch_st is entered 
and an exception event is handled.

catch pseudo states can also be associated to an state so that it acts 
as the default catch state for all the transitions from this state. We 
can see also an upper state as a exception-catcher.

src_st + event [guard] / action = dst_st

If an exception is throw on guard or action, the exception event is 
handled on the nesting state of src_st.

The interest of having local transition segments is that the exit of the 
current state is not called until there is an external transition segment.

src_st ^ event [guard] / action = dst_st

If an exception is throw on guard or action, the exception event is 
handled on src_st.

An exception throw on the dst_st entry should be handled by its nesting 
state.

Associating a single TOP level state to a SM allows to associate a catch 
state to the SM.

Of course transitions that throw from the catch state associated to the 
top level should be transported to the caller or the sender (depending 
on whether the mechanism is synchronous or asynchronous).

You can find some descriptions of UML and exception handling e.g. at [1] 
for activities or [2]. Look for UML exception handling on your preferred 
search engine.

Note that when we use the action_nextstate model, the action_next can 
catch the exception and do whatever is needed and possible go to a 
specific state after handling the error.

I don't know if all this is compatible with UML2 model, I believe UML2 
doesn't model  exceptions (C++ exceptions) on guards/actions. There is 
the concept of an exception signal, but I'm not sure this respond to 
what I'm asking for.

>   Suggestions are more
> than welcome as I'm not sure what would be the best solution here.
>
> Can you elaborate what you mean by `inheritance of state machines`, please?
> Is the question related to composite/sub state machines or just whether a
> state machine might be inherited?
A derived state machine can refine a base state machine in different ways:

1* adding new transitions
2* refining a state by adding sub-states and transitions
3* refining the next state of a transition with a sub-state of the 
derived next state (or an entry point, but I believe that MSM-lite has 
no entry/exit points associated to an state, isn't it?)
4* refining the guard of a transition
5* refining the action of a transition

I'm for at least the 3 first extension mechanisms. The last two can be 
emulated with virtual functions.
Point 3* could be not needed if the base class transitions make use of 
entry points.

[3] presents an OOHSM with abstract states.
>
> P.S. Sorry, I don't know how MSM or statecharts covers these subjects.
>
>
> MSM has a policy called `no_exception` which basically disable catching
> exceptions. Otherwise they are caught within the process_event.
Do you know what MSM does with the caught exception?
> Don't know how statechart is handling it.
>
>
Vicente

[1] http://edn.embarcadero.com/article/30169
[2] 
https://www.google.fr/url?sa=t&rct=j&q=&esrc=s&source=web&cd=3&cad=rja&uact=8&ved=0ahUKEwipzI_H2OHKAhWG2hoKHRHZCuwQFgg3MAI&url=http%3A%2F%2Fwww.mit.bme.hu%2F~pinter%2Fpublications-files%2Fpinter-majzik-2004-fidji-modeling-and-analysis-of-exception-handling-techniques-by-using-uml-statecharts.pdf&usg=AFQjCNEkHdkPZJT2Cn7A8qAyHXJ4W5zcrw&sig2=q5oZ9NfLd7GXnWkFdprb7Q
[3] 
https://www.google.fr/url?sa=t&rct=j&q=&esrc=s&source=web&cd=7&cad=rja&uact=8&ved=0ahUKEwjxp8qm3-HKAhWGWhQKHdnRA60QFghRMAY&url=http%3A%2F%2Fwww2.ic.uff.br%2F~esteban%2Ffiles%2Fcadabra.pdf&usg=AFQjCNE5KJWQr4m0RB87cgrnKFLDKjBj1A&sig2=uC0-Zikp3OoZVNjzXMUTJw