commons-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Rahul Akolkar" <rahul.akol...@gmail.com>
Subject Re: [scxml] Handling exceptions thrown by custom actions
Date Tue, 16 May 2006 18:55:23 GMT
On 5/16/06, Fasih <fasihullah.askiri@baypackets.com> wrote:
> That sure is a complex requirement :)
<snip/>

With derived events and history, I suspect this isn't complex (and I
agree its a common thing to want to do -- revert state transition on
recoverable failure -- hopefully to try something new the next time
;-).


> For the question if we can move the SCXML Engine to move to some state, I am
> not very sure (Where are you Rahul?).
> Also, you can look at the <history/> I dont really know what it does, maybe
> you should go through it once to see if it can help you someway.
>
<snap/>

I should add <history> examples. History is fun (and useful) stuff ;-)

If you want, please file an enhancement request in JIRA [1] for some
history examples. I will try to exercise my brain and remember this
one though. I guess I also need to update the issue tracking page
since it still refers to bugzilla, give me a day or so for that.

-Rahul

[1] http://issues.apache.org/jira/


> One more thing, the parallel error handler does pretty much what you are
> looking for except that it keeps you in the custom-action-state and not to
> the INITIAL State, I think you might have to write the handlers for each
> event.
>
> Not of much help I guess. :o
>
> +Fasih
>
> ----- Original Message -----
> From: "Nestor Urquiza" <nestoru@yahoo.com>
> To: "Jakarta Commons Users List" <commons-user@jakarta.apache.org>
> Sent: Tuesday, May 16, 2006 9:06 AM
> Subject: Re: [scxml] Handling exceptions thrown by custom actions
>
>
> > First thanks a lot for your reply and as always they
> > are full of ideas that are really helpful.
> >
> > Second for the particular problem I am presenting I
> > have now (Thanks to you) some valid approaches however
> > still I have to handle errors one by one and let us be
> > more specific "exceptions" which for my program means
> > that you should always return an error message in your
> > "System".
> >
> > My question then is a solution to handle thru just one
> > common way all of those Exceptional situations that
> > happen in the following usecase:
> >
> > 1)An external event comes to the System (HTTP GET or
> > POST for example).
> > 2)The System calls a Bridge which can returns the
> > control to the System given any Exception there before
> > it passes the request to the SCXML Engine.
> > 3)The Bridge pass the control to the SCXML Engine and
> > a transition from the INITIAL STATE (for this
> > transaction) to an Action State is performed.
> > 4)Within the onentry internal FSM event some custom
> > actions are performed as part of let us say setting
> > preconditions.
> > 5)If any Exception should be thrown from one of those
> > custom actions or specific-code (in any case java
> > methods) then the FSM should move to INITIAL STATE and
> > returns the control to the Bridge (which was the one
> > that triggered the FSM external event).
> >
> > Again, I think this is a very common situation in
> > which a transparent for the SCXML Engine solution
> > should exist. So I think that an internal call to the
> > SCXML Engine to restore the INITIAL state should
> > exists independently of what you of course have as
> > utils to handle errors from the SCXML Engine using all
> > the approaches you already mentioned.
> >
> > And then I will reformulate my question ;-)
> > Is there a way to instruct the SCXML Engine to go to
> > the initial state where the FSM was before the last
> > external event was triggered?
> >
> > --- Fasih <fasihullah.askiri@baypackets.com> wrote:
> >
> >> 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
<snip/>

---------------------------------------------------------------------
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