[evaluator] Preserve exceptions thrown from evaluation

[eclipse-ocl-bot]

| --- | --- | | Bugzilla Link | 327377 | | Status | NEW | | Importance | P3 enhancement | | Reported | Oct 09, 2010 00:41 EDT | | Modified | Feb 10, 2021 10:21 EDT | | Depends on | 570995 | | Reporter | Eike Stepper |

Description

From the newsgroup:

Shouldn't the exception be stored somewhere? E.g. in the result, the visitor, the evaluation environment or where ever. Just somewhere that I can access it after the evaluation has failed.

Yes. I've thought about this occasionally, but it's not that high on a much too long list of problems. Please raise a Bugzilla, so that I can't forget or dismiss it as one of my own ramblings.

It's not that easy:

a) OCL defines that there is exactly one invalid.\ b) OCL definjes that a bad evaluation is invalid.\ c) if an expression does ...oclIsInvalid() then invalid wasn't a problem.\ d) EMF throws a variety of RuntimeExceptions

I'm inclined to ignore a) since the uniqueness of invalid isn't sensibly observable, so an invalid-with-context should be feasible.

Regards

    Ed Willink

[eclipse-ocl-bot]

By Eike Stepper on Oct 09, 2010 01:16

I'm inclined to ignore a) since the uniqueness of invalid isn't sensibly observable, so an invalid-with-context should be feasible.

Isn't it possible for clients to obtain the invalid instance from somewhere so that per spec the following pseudo code would be allowed:

if (result == stdLib.getInvlaid()) ...

What about storing the diagnostic in a static ThreadLocal variable so that you can keep the singleton invalid instance but make the evaluation problems available for the evaluating thread?

[eclipse-ocl-bot]

By Ed Willink on Oct 09, 2010 05:05

Could you clarify your use case? Your original message suggested that your trouble may be due to the 'there-are-no-problems' character of the

public Object visitExpression(OCLExpression<C> expression) {

API that throws no exceptions, and then of course requires a non-exception return mechanism to be introduced to return them after all, and then has to provide a control mechanism to stop that alternate mechanism getting too verbose, and also to avoid intoducing a backward log-filling API incompatibility...

I can see one use case in which it might be nice to browse the intermediate results of an OCL evaluation to understand how invalids are arising and propagating.

I can see another use case in which OCL evaluation never returns invalid but instead throws as helpful an OclEvaluationException as possible.

I suspect that your problem is the latter use case, for which we can provide a new API. This might also integrate better with EMF validation, since EMF validation will catch the exception usefully.

[eclipse-ocl-bot]

By Eike Stepper on Oct 09, 2010 05:13

Runtime exceptions thrown from

try\ {\ return expression.accept(getVisitor());\ }

are caught but not propagated. Instead OCLInvalid is returned which carries no information about why it is invalid.

My use case is that my ExtentMap (lazily) calls a bunch of CDO methods that can throw arbitrary exceptions. Since these exceptions are not even logged somewhere I have trouble to find out what to do.

[eclipse-ocl-bot]

By Ed Willink on Oct 09, 2010 13:56

I'm enhancing the API of InvalidLiteralExp in the new Pivot model to support an Element context, an OclExpression node, a String reason and a Throwable, iff allowExplanatoryInvalids is configured.

invalid will therefore always be an InvalidLiteralExp but not necessarily the unique one. Easy enough to use instanceof to test for invalid.

I'm not sure whether to raise an OMG issue to endorse this. It's useful but are two invalids with different contexts really equal? With only one bottom, they obviously must be.

[eclipse-ocl-bot]

By Ed Willink on Mar 14, 2011 16:20

The pivot model evaluator implements 'invalid' as either of an InvalidValueException oe InvalidEvaluationException .

InvalidValueException is thrown internally when the context is unknown.\ InvalidEvaluationException is thrown when the context is known.

InvalidEvaluationException carries the EvaluationEnvironment at the point of failure enabling diagnostics to examine the full evaluation environment and variable stack.

The current API preserves compatibility. A cleaner inner API needs design to expose the exception.

[eclipse-ocl-bot]

By Ed Willink on May 27, 2014 11:13

(In reply to Ed Willink from comment #5)

The pivot model evaluator implements 'invalid' as either of an InvalidValueException oe InvalidEvaluationException .

Now just InvalidValueException with a nested Exception field.

[eclipse-ocl-bot]

By Ed Willink on Feb 10, 2021 10:21

(In reply to Eike Stepper from comment #1)

What about storing the diagnostic in a static ThreadLocal variable so that you can keep the singleton invalid instance but make the evaluation problems available for the evaluating thread?

Bug 570995 considers the trade-offs of ThreadLocal and ResourceSet adapter added value.

An OCLControlResource/Adapter in a ResourceSet could make hidden Exceptions visible in the Sample Ecore Editor.