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 Thu, 31 Aug 2006 04:57:07 GMT
On 8/30/06, Craig McClanahan <> wrote:
> On 8/28/06, Rahul Akolkar <> wrote:
> >
> >
> > 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").
> Is an FQN unambiguous compared to other possible event names?

Yes, if done right. The best practice in event names is that, like
package names, they imply a particular ontology, starting from the
broadest to the narrowest using "." as a separator. This is one of the
reasons I chose the "faces.outcome" event name. In the end, the event
names are decided by the user. As long as the user has a naming scheme
that is followed in the SCXML documents used for that usecase, we're

Another interesting usage of such a event naming scheme (which is
probably not immediately obvious) is that it also works like a
wildcard scheme (though this bit doesn't always translate well to the
Java exception FQNs) i.e. if the following is a candidate transition:

<transition event="error.send" ... />

when an event "error.send.targetunavailable" is triggered, the above
transition will be followed (since error.send.targetunavailable is
considered to be a "type of" error.send due to the implication of an

>  I suppose it
> could be if you disallowed "." in any other kind of name.  A couple of other
> thoughts on how one might express this:
> * An "exception:FQN" syntax that uses a prefix in the same spirit as
>   entering a dialog through a logical outcome that has a special prefix.
> * Since the guard condition can be an expression, some concise way
>   to evaluate an expression to see if an exception was thrown.

Sure, these are other options.


> Craig

View raw message