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@wanadoo.fr> 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-s... 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