Eclipse Community Forums: EMF "Technology" (Ecore Tools, EMFatic, etc) » Live validation and MSLActionAbandonedException

Help

Home

Home » Modeling » EMF "Technology" (Ecore Tools, EMFatic, etc) » Live validation and MSLActionAbandonedException

Show: Today's Messages :: Show Polls :: Message Navigator

Live validation and MSLActionAbandonedException [message #10043]

Tue, 10 January 2006 04:14

Dave Carlson

Messages: 402
Registered: July 2009

Senior Member

Hi,

I've defined one "Live" validation constraint in my simple UML editor based
on the validation tutorial examples. However, when the validation
constraint is violated while editing (test for empty "name" of a UML element
in my example) I get the MSLActionAbandonedException runtime exception that
results in a stack trace.

How are these supposed to be handled? Based on the validation preference
settings to open an error dialog for Live constraints, I expected this to be
caught and handled by the framework. I can't catch
MSLActionAbandonedException in my code because the compiler says it's not
thown by the try block. How do I handle these live validation exceptions?

Thanks. The EMF validation framework is a great contribution!
-- Dave Carlson

Report message to a moderator

Re: Live validation and MSLActionAbandonedException [message #10066 is a reply to message #10043]

Tue, 10 January 2006 13:46

Eclipse User

Originally posted by: cdamus.ca.ibm.com

Hi, Dave,

Thanks indeed for your vote of confidence.

Regarding MSLActionAbandonedException: that's a checked exception (not
runtime), so you should only need to catch it in invocations of the
MEditingDomain.runAsWrite(MRunnable) method, in which you perform changes
to your model. There shouldn't be any other context in which your changes
are validated by the GMF run-time. If this isn't the case, then we have an
issue to take up in the GMF newsgroup or bugzilla.

The validation preference for the error/warning dialog only pertains to user
feedback. It doesn't control the throwing of MSLActionAbandonedException,
because it is an important vehicle for telling client code that the changes
it thought it was making were not applied to the model after all. The idea
is like a transaction rollback exception in JDBC.

In general, the most appropriate way to handle MSLActionAbandonedException
is to report the embedded IStatus to the user via an ErrorDialog, because
the user's action violated one or more critical constraints installed by
the user. I don't think client code can implement a sensible recovery
strategy (e.g., retry) because the conditions in which the constraint is
violated cannot be expected to change. However, you may need to undo other
changes that were already successfully applied, perhaps even to non-EMF
resources.

HTH,

Christian

Dave Carlson wrote:

> Hi,
>
> I've defined one "Live" validation constraint in my simple UML editor
> based
> on the validation tutorial examples. However, when the validation
> constraint is violated while editing (test for empty "name" of a UML
> element in my example) I get the MSLActionAbandonedException runtime
> exception that results in a stack trace.
>
> How are these supposed to be handled? Based on the validation preference
> settings to open an error dialog for Live constraints, I expected this to
> be
> caught and handled by the framework. I can't catch
> MSLActionAbandonedException in my code because the compiler says it's not
> thown by the try block. How do I handle these live validation exceptions?
>
> Thanks. The EMF validation framework is a great contribution!
> -- Dave Carlson

Report message to a moderator

Re: Live validation and MSLActionAbandonedException [message #10089 is a reply to message #10066]

Tue, 10 January 2006 16:03

Dave Carlson

Messages: 402
Registered: July 2009

Senior Member

Thanks Christian. I used the wrong run() method on MEditingDomain

MEditingDomain.INSTANCE.run(
new ResourceSetModifyOperation("Rename Element") {

This method does not throw the checked exceptions, so I could not catch it.
Looks like I need to review these run alternatives -- plus the excellent
design document you created for the new emf-tx project.

"Christian W. Damus" <cdamus@ca.ibm.com> wrote in message
news:dq0dq5$qa9$1@utils.eclipse.org...
>
> Hi, Dave,
>
> Thanks indeed for your vote of confidence.
>
> Regarding MSLActionAbandonedException: that's a checked exception (not
> runtime), so you should only need to catch it in invocations of the
> MEditingDomain.runAsWrite(MRunnable) method, in which you perform changes
> to your model. There shouldn't be any other context in which your changes
> are validated by the GMF run-time. If this isn't the case, then we have
> an
> issue to take up in the GMF newsgroup or bugzilla.
>
> The validation preference for the error/warning dialog only pertains to
> user
> feedback. It doesn't control the throwing of MSLActionAbandonedException,
> because it is an important vehicle for telling client code that the
> changes
> it thought it was making were not applied to the model after all. The
> idea
> is like a transaction rollback exception in JDBC.
>
> In general, the most appropriate way to handle MSLActionAbandonedException
> is to report the embedded IStatus to the user via an ErrorDialog, because
> the user's action violated one or more critical constraints installed by
> the user. I don't think client code can implement a sensible recovery
> strategy (e.g., retry) because the conditions in which the constraint is
> violated cannot be expected to change. However, you may need to undo
> other
> changes that were already successfully applied, perhaps even to non-EMF
> resources.

Report message to a moderator

Re: Live validation and MSLActionAbandonedException [message #10157 is a reply to message #10089]

Wed, 11 January 2006 14:58

Eclipse User

Originally posted by: cdamus.ca.ibm.com

Oh, right,

That is a remnant of a legacy API that forgot some requirements. One of the
many reasons why we're cleaning up. ;-)

For now, the MRunnable-oriented API is your best bet. Hopefully emf-tx will
be better for you.

cW

Dave Carlson wrote:

> Thanks Christian. I used the wrong run() method on MEditingDomain
>
> MEditingDomain.INSTANCE.run(
> new ResourceSetModifyOperation("Rename Element") {
>
> This method does not throw the checked exceptions, so I could not catch
> it. Looks like I need to review these run alternatives -- plus the
> excellent design document you created for the new emf-tx project.
>
>
> "Christian W. Damus" <cdamus@ca.ibm.com> wrote in message
> news:dq0dq5$qa9$1@utils.eclipse.org...
>>

<snip>

Report message to a moderator