commons-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Nestor Urquiza <nest...@yahoo.com>
Subject Re: [scxml] Handling exceptions thrown by custom actions
Date Tue, 16 May 2006 14:10:24 GMT
Java code I will add ;-) so:

"Is there a way FROM JAVA CODE to instruct the SCXML
Engine to go to
the initial state where the FSM was before the last
external event was triggered?

Thanks!

--- Nestor Urquiza <nestoru@yahoo.com> wrote:

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


__________________________________________________
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


Mime
View raw message