commons-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Fasih" <fasihullah.ask...@baypackets.com>
Subject Re: [scxml] Handling exceptions thrown by custom actions
Date Tue, 16 May 2006 13:22:22 GMT
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.

:)
We go back to the post that we once had, have all your states as included 
states to a parent one, have an transition to the error state on an error 
event. This would however throw you off the current state.
Another way
<parallel>
<state id="worker">
<!-- Throws an exception event, but does not process it -->
</state>
<state id="error-handler">
<initial target="idle"/>
<state idle/>
<state handle-error/>
</state>
</parallel>
This way you will always be in the orig state and your error will be 
handled.

+Fasih
----- Original Message ----- 
From: "Nestor Urquiza" <nestoru@yahoo.com>
To: "Jakarta Commons Users List" <commons-user@jakarta.apache.org>
Sent: Tuesday, May 16, 2006 7:24 AM
Subject: Re: [scxml] Handling exceptions thrown by custom actions


>
>
> --- Fasih <fasihullah.askiri@baypackets.com> wrote:
>
>> Hi
>> When you say a custom action, I believe it is your
>> custom action.
>
> Yes I mean I am executing specific-code like assigning
> the result of a method to a variable.
>
> Now, going
>
>> by the Java programming practices, "dont catch an
>> exception if you cant
>> handle it and dont throw one when you know no-one
>> can catch it",
>
> Yep that is my dilema I should not cache this
> exception which is supposed to be handle as a critical
> error and so managed by either SCXML Engine or by some
> generic method in my "Bridge"
>
>>I would
>> rather fire an application.error event with the
>> exception msg as the payload
>> than throw the exception. To me it makes much more
>> sense as this is what the
>> SCXML can understand, else handle the exception in
>> Java.
>
> 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 ... 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.
>
> Wouldn't be easier to have a generic registration of
> the starting state using
> exec.getCurrentStatus().getStates() then whenever an
> exception occurs call a method to just return to that
> given initial state? Now if this is a valid approach
> which are the mothods you will use to accomplishing
> something like this?
>
>
>> By the way, looking at the API for execute I believe
>> that the concept of
>> derived events was added to signal that the event
>> has resulted from some
>> other event (As in an exception event as a result of
>> the orig event) once it
>> is an event, handling it would be simple.
>
> Interesting, could you put an example of this? Thanks
> a lot!,
> Nestor
>>
>> My thoughts anyways, there might be better
>> alternatives.
>>
>> +Fasih
>> ----- Original Message ----- 
>> From: "Nestor Urquiza" <nestoru@yahoo.com>
>> To: "Jakarta Commons Users List"
>> <commons-user@jakarta.apache.org>
>> Sent: Monday, May 15, 2006 9:47 AM
>> Subject: [scxml] Handling exceptions thrown by
>> custom actions
>>
>>
>> > Hello guys,
>> > Could you point me to what you think might be the
>> best
>> > approach here?
>> >
>> > I receive a request and pass that request to the
>> scxml
>> > engine by means of triggering the proper event.
>> The
>> > event then put the FSM in an action state where
>> some
>> > internal methods (custom actions) are called.
>> >
>> > How could I just suspend the whole execution of
>> the
>> > trigger and go back to the state the application
>> was
>> > before receiving the external event? Right now if
>> an
>> > exception is thrown from a custom action then a
>> new
>> > SCXMLExpressionException(e) is thrown as well so
>> the
>> > FSM stops and therefore the FSM stops at the
>> action
>> > state while of course I want it to go back to the
>> > original state.
>> >
>> > Thanks a lot,
>> > Nestor Urquiza
>> >
>> > __________________________________________________
>> > 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
>>
>>
>
>
> __________________________________________________
> 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