On 5/2/07, Torsten Krah <[EMAIL PROTECTED]> wrote:
Hi.
Got some question.
onError events at scxml level are reported by the SimpleErrorReporter.
Is there a way in shale, to plug in other ExceptionHandling classes?
I thought something about "onError" as xml element.
onTransition, onEntry and onExit are also interesting.
First one is the more important.
For now, every exception thrown in action states (failed initalizations
etc. pp) are catched and the real cause is not reported.
<snip/>
As an aside (I'll adress the main question below) -- I can look into
improving the error reporting. I'm traveling (without access to a dev
box) for a couple of weeks more, so if you want to file a JIRA ticket,
this will stay on the radar. Might require changes to the Commons
library, if it is the one not bubbling the real cause.
I want to plug in some ErrorHandling class which does take the Exception
- redirect to a defined "error page" and exits the "dialog" wich is
currently in progress.
Is this possible with current implementation, or something else near
that?
<snap/>
No, but I agree it should be. As you're probably aware, the dialog
implementations have maintained the DialogContext abstraction (the DC
impls are package private). However, there are a bunch of services
that the Commons SCXML impl has the ability to provide, which are
currently shielded behind the abstraction (note that
on{Entry,Transition,Exit} you mention above are exposed). There are a
couple of avenues going forward:
1) Continue to maintain this abstraction, in which case additional
vocabulary would need to be added to the SCXML dialog-config.xml DTD.
2) Make the SCXMLDialogContext public such that knowing that an
application is using SCXML dialogs, it will be possible to cast to an
implementation specific API (which can then expose the underlying
SCXMLExecutor, and all the Commons SCXML APIs that provide additional
functionality).
As much as the first one is cleaner, I/we will probably loathe having
to maintain another involved vocabulary for the dialog-config (and
perhaps so will those having to use it). Similarly, while the second
one will provide an all access card at the expense of an
implementation specific cast, it also implies greater responsibility
since direct interactions with the SCXMLExecutor are getting at the
heart of the mechanics of the dialog execution itself.
Opinions welcome.
-Rahul
Torsten
