commons-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Fasihullah Askiri <fasihullah.ask...@baypackets.com>
Subject Re: [scxml] Handling exceptions thrown by custom actions
Date Thu, 25 May 2006 13:56:28 GMT
Do have a look at the Wiki
I have posted an example solution using history, it looks neat. I have
not posted the code, but if you want I can send the code (in the form
of an SCXMLUnitTeestCase)

+Fasih


Nestor Urquiza wrote:

>Thanks you all for this. I am amnaging it now defining
>a generic internal error event called "app.error" and
>in every state I decide where to go if this event
>appears. Since I am triggering using
>"TriggerEvent.ERROR_EVENT" it has more priority the
>state machine just follow the error event.
>
>Below a snippet that I hope can be useful for someone
>looking at how to manage an exception within custom
>actions to return to the desired state (which in my
>case was the initial one).
>
><code>
> 
>         public void triggerErrorEvent(String event)
>throws ModelException
>         {
>            TriggerEvent[] evts = new TriggerEvent[1];
>            evts[0] = new TriggerEvent(event,
>                  TriggerEvent.ERROR_EVENT, null);
>            exec.triggerEvents(evts);
>            return;
>         }
>          
>            public void triggerErrorEvent() throws
>ModelException
>            {
>               TriggerEvent[] evts = new
>TriggerEvent[1];
>               evts[0] = new
>TriggerEvent(Constants.SCXML_DEF_INT_ERROR_EVENT,
>                                                
>TriggerEvent.ERROR_EVENT, null);
>               exec.triggerEvents(evts);
>               return;
>            }
>
>If Constants.SCXML_DEF_INT_ERROR_EVENT="app.error"
>then:
><n:transition event="app.error" target="IDDLE"/>
>will be executed whenever a critical error has to be
>handled within the given state and in this case it
>will return to IDDLE for example.
></code>
>
>
>--- Rahul Akolkar <rahul.akolkar@gmail.com> wrote:
>
>  
>
>>On 5/16/06, Nestor Urquiza <nestoru@yahoo.com>
>>wrote:
>>    
>>
>><snip/>
>>    
>>
>>>I understand then you are talking about using:
>>><transition event="application.error"
>>>      
>>>
>>target="error"/>
>>    
>>
>>>and I assume that your approach is related to call
>>>from the exception catch block
>>>exec.triggerEvents(evts); whre evts contains
>>>"application.error" and I already did it ... and
>>>thanks it is a valid solution ...
>>>      
>>>
>><snap/>
>>
>>I'd rather use derived events for that as mentioned
>>earlier in the
>>thread (for reasons such as the ones you mention
>>below). Conceptually,
>>you can think of the events as coming in via two
>>FIFOs:
>>
>> * External events (the bridge is "feeding" the
>>engine external
>>events, and is also responsible to synchronize the
>>triggerEvent()
>>calls etc.)
>>
>> * Internal / derived events (populated via the
>>"side-effects" of each
>>external event, such as outcomes of custom actions,
>>and these must be
>>processed *before* the next external event)
>>
>>-Rahul
>>
>>
>>    
>>
>>>however I can see
>>>two problems:
>>>1)You need to include a line managing errors in
>>>      
>>>
>>every
>>    
>>
>>>single state that can as result of custom actions
>>>throw an exception.
>>>2)In case of states that can result from two
>>>transitions comming from two different states then
>>>      
>>>
>>you
>>    
>>
>>>cannot use a generic call "application.error" and
>>>      
>>>
>>so
>>    
>>
>>>your "Bridges" would be doing decisions that
>>>      
>>>
>>ideally
>>    
>>
>>>should be done by the SCXML Engine thru an EL.
>>>
>>>      
>>>
>><snap/>
>>
>>
>>    
>>
>---------------------------------------------------------------------
>  
>
>>To unsubscribe, e-mail:
>>commons-user-unsubscribe@jakarta.apache.org
>>For additional commands, e-mail:
>>commons-user-help@jakarta.apache.org
>>
>>
>>    
>>
>
>
>__________________________________________________
>Do You Yahoo!?
>Tired of spam?  Yahoo! Mail has the best spam protection around 
>http://mail.yahoo.com 
>
>---------------------------------------------------------------------
>To unsubscribe, e-mail: commons-user-unsubscribe@jakarta.apache.org
>For additional commands, e-mail: commons-user-help@jakarta.apache.org
>
>  
>


---------------------------------------------------------------------
To unsubscribe, e-mail: commons-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-user-help@jakarta.apache.org


Mime
View raw message