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 17:12:34 GMT
Thanks Fasih!, 
I think I will wait for a Rahul answer here ... 
I hope you are doing well Rahul ... for the sake of
all of us :-)
Cheers!,
Nestor

--- Fasih <fasihullah.askiri@baypackets.com> wrote:

> That sure is a complex requirement :)
> 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.
> 
> 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
> >> ----- 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
> >
> > 
> 
> 
> 
>
---------------------------------------------------------------------
> 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