Eclipse Community Forums: EMF » How should a derived property fail?

Help

Home

Home » Modeling » EMF » How should a derived property fail?

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

How should a derived property fail? [message #1827293]

Tue, 12 May 2020 11:34

Ed Willink

Messages: 7581
Registered: July 2009

Senior Member

Hi

A derived property must use custom code to support computation of the derived value. Fine but what if that computation fails?

In Java, we might expect to throw an exception, and looking at EStructuralFeatureImpl we can see that CCE, IAE, RTE, UOE can happen mostly in impossible but also in some stupid circumstances..

If we throw an Exception, we break the EValidator's requirement that no individual validation throw an exception because when EObjectValidator.validate_DataValueConforms invokes eIsSet for the derived property the exception is thrown and the whole validation crashes.

If we don't throw an exception, what should the return be? null/0/false will often do, but they can incorrectly be interpreted as is-set/is-not-set causing a missing validation diagnostic.

It seems to me that at least EObjectValidator.validate_DataValueConforms and EObjectValidator.validate_MultiplicityConforms should have try/catch to fix the impedance mismatch between exception-throwing user code and no-exception validate.

Is a Bug required or have I misunderstood the semantics?

This query triggered by https://bugs.eclipse.org/bugs/show_bug.cgi?id=563092 which seemed like an OCL bug until it seemed like it wasn't after all.

Regards

Ed Willink

Report message to a moderator

Re: How should a derived property fail? [message #1827297 is a reply to message #1827293]

Tue, 12 May 2020 14:42

Ed Merks

Messages: 32743
Registered: July 2009

Senior Member

Operations can be expected to throw exceptions, but derived features should behave like ordinary features. After all, the properties view isn't going to like these things throwing exceptions either. In fact no reflective code in the framework nor in downstream frameworks will generally be happy to find exceptions being thrown simply while data is being accessed. Going down the path of 'every eGet call must be surrounded by a try/catch' seems like the dark path to me because that path doesn't just stop at the validator. Even there, there are 13 calls to it in EObjecctValidator as well as two calls to eIsSet. How can one use such API when every call is potentially suspect, though only because of user errors in manually coded logic?

Ed Merks
Professional Support: https://www.macromodeling.com/

Report message to a moderator

Re: How should a derived property fail? [message #1827299 is a reply to message #1827297]

Tue, 12 May 2020 15:38

Ed Willink

Messages: 7581
Registered: July 2009

Senior Member

Thanks. Yes. Quote:

derived features should behave like ordinary features

is a very sensible philosophy. Just leaves the problem of how to avoid the user error getting out of hand. I guess catching the exception before it propagates and converting it to default, plus an error log entry, is the way to go.

Report message to a moderator

Re: How should a derived property fail? [message #1827325 is a reply to message #1827299]

Wed, 13 May 2020 07:21

Ed Willink

Messages: 7581
Registered: July 2009

Senior Member

Yes, but that isn't the issue. Perhaps I should have asked "How should an ordinary feature fail?"

It would appear to be the "inalienable right of any Java code snippet to crash" by throwing a RunTimeException. A badly coded getXXXGen may do this. Presumably a CDO getXXX may crash if something bad happens to the CDO repo. EMF features crash if the feature is not applicable to the EClass - common with metamodel schizophrenia.

The trigger for this problem was that auto-generated code from OCL observes the same philosophy as EMF; do not incur gratuitous overheads to accommodate ill-formed models. It is a user responsibility to provide well-formed input.

By default, a crash is handled by the Java application launcher by providing a diagnostic stack trace. However user code can catch a crash much earlier and as you observe recoding to catch exeception from every eGet is a dark prospect. The EMF philosophy of avoiding overheads and assuming well-formed models is appropriate.

However Diagnostian.validate() is a unique application specifically designed to help the user understand how their model is not well-formed. Diagnostian.validate() must therefore accommodate the user model's failure to satisfy the preconditions of much of the code it executes. Diagnostian.validate() should not fail totally because of an ill-formedness.

Again the particular problem that triggered this query was that a multiplicity violation in object A caused the multiplicity violation of object B to crash. The result was an obscure stack trace for the crash of the B validation. The potentially helpful diagnostic for A was either not generated because B had already crashed, or was generated but was not communicated to the user, because B crashed.

It seems to me that there should be a crash catch at the boundary between the outer Diagnostian.validate() functionality that accommodates ill-formedness and the inner EMF calls that presume well-formedness. i.e. each validate loop over multiple EObjects should catch the crash from each bad EObject so that a crash per really bad EObject is reported and useful diagnostics per slightly bad EObject occur as normal. Diagnostian.validate() as a whole should never crash as a consequence of a bad EObject.

This is just the same policy as is required for code that scans the EPackage.Registry; an exception for each entry must be caught to avoid the overall application crashing from a single rogue extension point declaration such as that provided by WST in the past.

Report message to a moderator

Re: How should a derived property fail? [message #1827335 is a reply to message #1827325]

Wed, 13 May 2020 09:14

Ed Merks

Messages: 32743
Registered: July 2009

Senior Member

The validator is intended to validate instances. If the meta model of the instance is itself ill-behaved or is perhaps is an ill-formed Ecore model, the validator is just not designed to help validate the underlying metamodel itself nor any underlying implementation mistakes in a generated meta model nor in any manually coded logic in that implementation. It's not a meta validator and it is not designed as a way to test the integrity of the model implementation. It's impossible to comment on the obscurity of the exception nor is it clear how a catch should handle such exception and how how that would help make it all less obscure.

Ed Merks
Professional Support: https://www.macromodeling.com/

Report message to a moderator

Re: How should a derived property fail? [message #1827422 is a reply to message #1827335]

Thu, 14 May 2020 09:59

Ed Willink

Messages: 7581
Registered: July 2009

Senior Member

I'm not sure what you mean by meta validator but to check that we're on the same page let's have a repro.

5 files/message limit => the current state this message, a fixed state => next message.

ValidationBug.zip is a zipped project that contains my reconstruction of the user's bad model and consequent OCL2Java auto-generation. (Load in Eclipse).

Model.xmi is an instance model. Load in nested Eclipse and Sample Ecore Model Editor.

BadLive.dbg is the live validation display. It shows no problems (because live validation crashed silently). Or if you have been evolving Model.xmi, it shows the stale problem markers from the last non-crashing LIve Valudation - very confusing.
index.php/fa/38111/0/

BadBulk.png shows the popup dialog diagnosing the crash of a bulk Validate.
index.php/fa/38112/0/

BadEvent.png shows the associated Error Log entry (with a blank message!)
index.php/fa/38113/0/

Attachment: ValidationBug.zip
(Size: 96.13KB, Downloaded 72 times)
Attachment: Model.xmi
(Size: 0.41KB, Downloaded 94 times)
Attachment: BadLive.png
(Size: 8.26KB, Downloaded 219 times)
Attachment: BadBulk.png
(Size: 6.42KB, Downloaded 207 times)
Attachment: BadEvent.png
(Size: 22.51KB, Downloaded 227 times)

Report message to a moderator

Re: How should a derived property fail? [message #1827425 is a reply to message #1827422]

Thu, 14 May 2020 10:08

Ed Willink

Messages: 7581
Registered: July 2009

Senior Member

If we apply a patch to Diagnostician with a per-element try-catch...

OkLive.png now shows many issues in the Live Validation.
index.php/fa/38115/0/

OkBulk.png now shows the issues and a stack trace in the traditional bulk Validate.
index.php/fa/38116/0/

The patch demonstrates that the Diagnostician is easily and very usefully converted from a tool that makes the unsound assumption that the model to be validated is well-formedly ill-formed to a validator that gives considerably more assistance in diagnosing really rubbish model/tooling.

(The try-catch in the patch is not where I expected; there may be a different validate call-chain that needs a similar try-catch.)

Attachment: Use-trycatch-to-show-crashed-validations.patch
(Size: 3.21KB, Downloaded 79 times)
Attachment: OkLive.png
(Size: 21.70KB, Downloaded 205 times)
Attachment: OkBulk.png
(Size: 41.25KB, Downloaded 203 times)

Report message to a moderator

Re: How should a derived property fail? [message #1827472 is a reply to message #1827425]

Fri, 15 May 2020 06:57

Andrzej Wąsowski

Messages: 21
Registered: November 2019

Junior Member

Ed M, this does look like a useful change to help users that Ed W proposes ... Not much code but the feedback is much better.

Report message to a moderator

Re: How should a derived property fail? [message #1827475 is a reply to message #1827472]

Fri, 15 May 2020 10:08

Ed Merks

Messages: 32743
Registered: July 2009

Senior Member

All this appears to do is keep going with validation, but the information about what causes the "crash" is no different than what's in the log in any case. All there is is a stack trace and in either, that problem needs to be fixed before the validation should be inflicted on actual users of the model. If someone cares to produce a Gerrit review, then I can try to fit that into my other higher priority volunteer work.

Ed Merks
Professional Support: https://www.macromodeling.com/

Report message to a moderator