shale-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Rahul Akolkar" <>
Subject Re: [dialog] Requirement: Uncaught exception ends dialog?
Date Tue, 29 Aug 2006 05:18:09 GMT
On 8/29/06, Craig McClanahan <> wrote:
> On 8/28/06, Paul Spencer <> wrote:
> >
> >
> > Treat an exception like a transition.  Thus allowing then next state to be
> > a view, action, subdialog or end.  A dialog default also can be
> > configured.
> >
> > <dialog name="EnterCustomer"
> >          start="enterCustomer"
> >          defaultException="displayException" ...>
> >    <transition exception="SqlException" target="pleaseCallTheDBA"/>
> >    <view name="enterCustomer"...>
> >      <tranistion outcome="success" target="saveCustomer"/>
> >    </view>
> >    <action name="saveCustomer">
> >      <transition exception="CustomerAlreadyExists" target="editCustomer"/>
> >      <transition outcome="success" target="done"/>
> >    </action>
> >    <view name="editCustomer".../>
> >    <end name="done".../>
> >    <end name="pleaseCallTheDBA".../>
> >    <end name="displayException".../>
> > </dialog>
> Now *that* is definitely clever -- and we can even couple it with the
> behavior of a servlet container (exception declarations work for that
> exception or any subclass of that exception) to be even more consistent with
> the overall platform.

SWF has been doing this exact thing for a while now, the related
attribute on the transition element is called "on-exception" (the
usual logical outcome is handled via "on").

>  It's pretty clear what to do with our classic syntax
> for dialog configs.  It'll be interesting to see how we might be able to
> model this idea when we can't change the schema for the state machine
> configuration (i.e. such as SCXML).

Correct, that schema is immutable as far as we're concerned. And for
obvious reasons, since we can't really model an on-exception
transition attribute in a UML state chart (its too Java specific) or
in classical state chart theory either. But what it can be treated as,
is simply an event whose name is the FQN of the exception (this is
what we've been promoting as the best practice, especially in the
realm of SCXML custom actions, where such executable content may throw
"derived events").

The standard actions (which shale-dialog2-scxml will use) however do
not support such a mechanism in v0.5. It will be easily possible to
add this to the standard actions as well (so any exceptions therein
cause a derived event to be triggered as mentioned above).

I consider this to be a J2EE (or Java) specific enhancement, and not
part of the baseline state machine abstraction, since after all, with
a bit more diligence in authoring, an exception can be turned into a
first-class logical outcome.


> >
> > Paul Spencer
> >
> Craig

View raw message