NPE on helper without operation body

[eclipse-qvt-oml-bot]

| --- | --- | | Bugzilla Link | 447905 | | Status | NEW | | Importance | P3 normal | | Reported | Oct 20, 2014 08:05 EDT | | Modified | Oct 21, 2014 04:54 EDT | | Version | 3.4.0 | | Reporter | Christopher Gerking |

Description

A helper without an operation body results in an NPE, which is certainly not the intended behavior.

Should it return null instead? Should there be a compile error? Can the 'abstract' keyword help do distinguish legal from erroneous declarations?

[eclipse-qvt-oml-bot]

By Christopher Gerking on Oct 20, 2014 08:13

Maybe the discussions on bug 428028 or bug 428189 provide some hints on how to handle this case?

[eclipse-qvt-oml-bot]

By Christopher Gerking on Oct 20, 2014 08:23

Furthermore, I wonder why this case doesn't at least produce 'invalid', as intended for bug 415660. The reason is that QvtOperationalEvaluationVisitorImpl catches RuntimeException in executeImperativeOperation() and converts it into a QvtRuntimeException which bypasses the conversion to 'invalid'. I'm not sure if this behavior is appropriate.

[eclipse-qvt-oml-bot]

By Ed Willink on Oct 21, 2014 03:06

bug 428189 discussed body-less mappings rather than helpers, but helpers too can be a polymorphic hierarchy.

My normal expectation, from C/C++, is that a bodyless definition is a forward declaration that resolves parsing difficulties or an external declaration.

Forward referencing is unspecified in QVTo, but many statements in OCL/QVT only make sense as the ultimate truth of the parsing/analysis, so I take the view that there is no prohibition on forward references in QVT and so no need for pre-declarations.

Therefore a bodyless mapping is either a typo for a missing 'blackbox' or a typo for an empty body.

Since the current behavior is NPE, backward compatibility is not a problem.

Suggest:

at run time, empty non-blackbox helper body returns invalid.

at compile time empty non-abstract non-blackbox helper body is a warning, ideally offering 'abstract' or 'blackbox' or '{}' as quickfixes.

If/when we have a strict option, change the warning to error.

[eclipse-qvt-oml-bot]

By Ed Willink on Oct 21, 2014 03:20

(In reply to Ed Willink from comment #3)

at run time, empty non-blackbox helper body returns invalid.

Except that, see Bug 440813, when used in an imperative context a to-be-specified exception should be thrown.

[eclipse-qvt-oml-bot]

By Christopher Gerking on Oct 21, 2014 03:23

By the way, does OCL provide semantics for 'abstract' operations? QVTo seems not, and I still wonder if the implemented behavior for abstract mappings (i.e. may have a body, but must not be invoked directly, only merged/inherited) is profound or just a guess.

[eclipse-qvt-oml-bot]

By Ed Willink on Oct 21, 2014 04:54

The semantics of operation overloading and dispatch are left as a variation point in UML and are not specified in UML, leaving both UML and OCL with a gaping hole.

In various discussions I have found no objections to using Java-like semantics. The Ecore-based OCL has an evaluation preference to select dynamic dispatch. The Pivot-based OCL only supports dynamic dispatch, with the extra elaboration that OclSelf may be used in a type signature so that Real::"-"(OclSelf) automatiocally dispatches to Real::"-"(OclSelf) or Integer::"-"(OclSelf) according to the common type of two arguments.

I hope that QVT ?2.x will clarify in similar fashion, with the slight proviso that the Package behavior of xxxTransformation may vanish in favour of a clean Class inheritance. xxxTransformation should be nested within one of more Packages to establish name qualification.