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

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

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

Tue, 12 May 2020 07:34

Eclipse User

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

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

Tue, 12 May 2020 10:42

Eclipse User

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?

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

Tue, 12 May 2020 11:38

Eclipse User

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.

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

Wed, 13 May 2020 03:21

Eclipse User

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.

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

Wed, 13 May 2020 05:14

Eclipse User

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.

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

Thu, 14 May 2020 05:59

Eclipse User

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 110 times)
Attachment: Model.xmi
(Size: 0.41KB, Downloaded 134 times)
Attachment: BadLive.png
(Size: 8.26KB, Downloaded 378 times)
Attachment: BadBulk.png
(Size: 6.42KB, Downloaded 359 times)
Attachment: BadEvent.png
(Size: 22.51KB, Downloaded 372 times)

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

Thu, 14 May 2020 06:08

Eclipse User

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 144 times)
Attachment: OkLive.png
(Size: 21.70KB, Downloaded 347 times)
Attachment: OkBulk.png
(Size: 41.25KB, Downloaded 361 times)

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

Fri, 15 May 2020 02:57

Eclipse User

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.

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

Fri, 15 May 2020 06:08

Eclipse User

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.

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

Sat, 16 May 2020 04:06

Eclipse User

Ed Merks wrote on Fri, 15 May 2020 06:08

If someone cares to produce a Gerrit review

https://bugs.eclipse.org/bugs/show_bug.cgi?id=563242

Previous Topic:	Convert http://... to platform:/plugin/... URI
Next Topic:	Ecore/Genmodel override "Root Extends Interface"

Goto Forum:

-=] Back to Top [=-

Current Time: Sat Mar 22 09:25:50 EDT 2025

.:: Contact :: Home ::.

Breadcrumbs

Sign up to our Newsletter