Home » Modeling » EMF "Technology" (Ecore Tools, EMFatic, etc) » Live validation and MSLActionAbandonedException
|
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
|
|
|
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.
|
|
|
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>
|
|
|
Re: Live validation and MSLActionAbandonedException [message #562667 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
|
|
|
Re: Live validation and MSLActionAbandonedException [message #562691 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.
|
|
|
Re: Live validation and MSLActionAbandonedException [message #562759 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>
|
|
|
Goto Forum:
Current Time: Sun Dec 08 04:14:26 GMT 2024
Powered by FUDForum. Page generated in 0.03961 seconds
|