Many of our OCL constraints involve complex chained expressions referencing
modelled features and query operations, any part of which could be
undefined.

According to "OCL 2.0 Specification ptc/2005-06-06" Paragraph 7.4.11 (?)
"Undefined Values":
"Some expressions will, when evaluated, have an undefined value. For
instance, typecasting with oclAsType() to a type that the object does not
support or getting the ->first() element of an empty collection will result
in undefined. In general, an expression where one of the parts is undefined
will itself be undefined..." However, in practice I see
NullPointerExceptions when such expressions are evaluated. For example:

throws NPE if getInboundValueBinding() returns an empty list, apparently as
a result of attempting to using Java reflection APIs to invoke the
getOppositeEndpoint() method on a null reference. At present the only way
around this is to make the OCL expressions self-null-checking, which
obviously makes them more complicated than the spec. suggests they need be,
less readily comprehensible and (presumably) less performant.

The OCL 2.0 specification was never consistenly updated to redefine the
'undefined' value as the 'null' and the 'invalid' functionality. Most
of the MDT-OCL behaviour can be justified by one of the many
contradictory statements in the specification; though NPEs can never be
right. Please submit your example as a Bugzilla and we'll fix it.

We are currently resolving a variety of areas where the treatment of
null and invalid is not quite right.

Issue 14197 is our best guess at what is correct and we might have
it implemented by M3 or perhaps M4.

For now I'm afraid you just need to do excess empirical testing.

Regards

Ed Willink

Adrian Price wrote:
> Good day mdt.ocl,
>
> Many of our OCL constraints involve complex chained expressions referencing
> modelled features and query operations, any part of which could be
> undefined.
>
> According to "OCL 2.0 Specification ptc/2005-06-06" Paragraph 7.4.11 (?)
> "Undefined Values":
> "Some expressions will, when evaluated, have an undefined value. For
> instance, typecasting with oclAsType() to a type that the object does not
> support or getting the ->first() element of an empty collection will result
> in undefined. In general, an expression where one of the parts is undefined
> will itself be undefined..." However, in practice I see
> NullPointerExceptions when such expressions are evaluated. For example:
>
> inv inParamControlDisabled: let opposite : Bindable =
> getInboundValueBinding()->first().getOppositeEndpoint(self).target in
> enabled.value and opposite.oclIsKindOf(Parameter) implies
> opposite.oclAsType(Parameter).inout <> InOutType::IN
>
> throws NPE if getInboundValueBinding() returns an empty list, apparently as
> a result of attempting to using Java reflection APIs to invoke the
> getOppositeEndpoint() method on a null reference. At present the only way
> around this is to make the OCL expressions self-null-checking, which
> obviously makes them more complicated than the spec. suggests they need be,
> less readily comprehensible and (presumably) less performant.
>
> Is my understanding of the OCL spec. flawed or is this a bug?
>
> Thanks in advance,
>
> Adrian Price
> Senior Architect
> TIBCO Software, Inc.
>
>

Many thanks for the response and detailed explanation. I myself had found
the OCL spec. rather confusing as to the semantics of undefined / invalid /
null and your proposed revisions offer some reassurance that it wasn't just
me being slow on the uptake.

I'm putting together a JUnit test case to illustrate the problems I've seen,
will post to here and Bugzilla when complete. BTW the JUnit is not so
straightforward since OCL does not have a syntax for declaring an empty
explicitly typed collection literal. For example (using classes from the
Ecore package for convenience) none of: OrderedSet(EClass)->first(),
OrderedSet(EClass){}->first(), OrderedSet()->first() or
OrderedSet{}->first() appear to be valid OCL. BTW the production
CollectionLiteralExpCS ::= CollectionTypeIdentifierCS '{'
CollectionLiteralPartsCS? '}' permits an empty element list but for the
fourth example in the previous sentence MDT/OCL throws the parser exception
"Argument is null, expected a List".

Thanks & regards,

Adrian.

"Ed Willink" <ed@willink.me.uk> wrote in message
news:h7mk2f$p27$1@build.eclipse.org...
> Hi Adrian
>
> The OCL 2.0 specification was never consistenly updated to redefine the
> 'undefined' value as the 'null' and the 'invalid' functionality. Most
> of the MDT-OCL behaviour can be justified by one of the many contradictory
> statements in the specification; though NPEs can never be right. Please
> submit your example as a Bugzilla and we'll fix it.
>
> I posted a substantive revised text to resolve 'null' and 'invalid' as
> http://www.omg.org/issues/ocl2-rtf#Issue14197. We are working to have an
> unambiguous specification and an implementation compliant with it.
>
> The corresponding rationalisation of invalid/Invalid/OclInvalid was
> applied to CVS HEAD yesterday as part of
> https://bugs.eclipse.org/bugs/show_bug.cgi?id=282882.
>
> We are currently resolving a variety of areas where the treatment of
> null and invalid is not quite right.
>
> Issue 14197 is our best guess at what is correct and we might have
> it implemented by M3 or perhaps M4.
>
> For now I'm afraid you just need to do excess empirical testing.
>
> Regards
>
> Ed Willink
>
>
> Adrian Price wrote:
>> Good day mdt.ocl,
>>
>> Many of our OCL constraints involve complex chained expressions
>> referencing modelled features and query operations, any part of which
>> could be undefined.
>>
>> According to "OCL 2.0 Specification ptc/2005-06-06" Paragraph 7.4.11 (?)
>> "Undefined Values":
>> "Some expressions will, when evaluated, have an undefined value. For
>> instance, typecasting with oclAsType() to a type that the object does not
>> support or getting the ->first() element of an empty collection will
>> result in undefined. In general, an expression where one of the parts is
>> undefined will itself be undefined..." However, in practice I see
>> NullPointerExceptions when such expressions are evaluated. For example:
>>
>> inv inParamControlDisabled: let opposite : Bindable =
>> getInboundValueBinding()->first().getOppositeEndpoint(self).target in
>> enabled.value and opposite.oclIsKindOf(Parameter) implies
>> opposite.oclAsType(Parameter).inout <> InOutType::IN
>>
>> throws NPE if getInboundValueBinding() returns an empty list, apparently
>> as a result of attempting to using Java reflection APIs to invoke the
>> getOppositeEndpoint() method on a null reference. At present the only way
>> around this is to make the OCL expressions self-null-checking, which
>> obviously makes them more complicated than the spec. suggests they need
>> be, less readily comprehensible and (presumably) less performant.
>>
>> Is my understanding of the OCL spec. flawed or is this a bug?
>>
>> Thanks in advance,
>>
>> Adrian Price
>> Senior Architect
>> TIBCO Software, Inc.

Adrian Price wrote:
> Hi Ed,
>
> Many thanks for the response and detailed explanation. I myself had found
> the OCL spec. rather confusing as to the semantics of undefined / invalid /
> null and your proposed revisions offer some reassurance that it wasn't just
> me being slow on the uptake.
>
> I'm putting together a JUnit test case to illustrate the problems I've seen,
> will post to here and Bugzilla when complete. BTW the JUnit is not so
> straightforward since OCL does not have a syntax for declaring an empty
> explicitly typed collection literal. For example (using classes from the
> Ecore package for convenience) none of: OrderedSet(EClass)->first(),
> OrderedSet(EClass){}->first(), OrderedSet()->first() or
> OrderedSet{}->first() appear to be valid OCL. BTW the production
> CollectionLiteralExpCS ::= CollectionTypeIdentifierCS '{'
> CollectionLiteralPartsCS? '}' permits an empty element list but for the
> fourth example in the previous sentence MDT/OCL throws the parser exception
> "Argument is null, expected a List".
>
> Thanks & regards,
>
> Adrian.
>
> "Ed Willink" <ed@willink.me.uk> wrote in message
> news:h7mk2f$p27$1@build.eclipse.org...
>> Hi Adrian
>>
>> The OCL 2.0 specification was never consistenly updated to redefine the
>> 'undefined' value as the 'null' and the 'invalid' functionality. Most
>> of the MDT-OCL behaviour can be justified by one of the many contradictory
>> statements in the specification; though NPEs can never be right. Please
>> submit your example as a Bugzilla and we'll fix it.
>>
>> I posted a substantive revised text to resolve 'null' and 'invalid' as
>> http://www.omg.org/issues/ocl2-rtf#Issue14197. We are working to have an
>> unambiguous specification and an implementation compliant with it.
>>
>> The corresponding rationalisation of invalid/Invalid/OclInvalid was
>> applied to CVS HEAD yesterday as part of
>> https://bugs.eclipse.org/bugs/show_bug.cgi?id=282882.
>>
>> We are currently resolving a variety of areas where the treatment of
>> null and invalid is not quite right.
>>
>> Issue 14197 is our best guess at what is correct and we might have
>> it implemented by M3 or perhaps M4.
>>
>> For now I'm afraid you just need to do excess empirical testing.
>>
>> Regards
>>
>> Ed Willink
>>
>>
>> Adrian Price wrote:
>>> Good day mdt.ocl,
>>>
>>> Many of our OCL constraints involve complex chained expressions
>>> referencing modelled features and query operations, any part of which
>>> could be undefined.
>>>
>>> According to "OCL 2.0 Specification ptc/2005-06-06" Paragraph 7.4.11 (?)
>>> "Undefined Values":
>>> "Some expressions will, when evaluated, have an undefined value. For
>>> instance, typecasting with oclAsType() to a type that the object does not
>>> support or getting the ->first() element of an empty collection will
>>> result in undefined. In general, an expression where one of the parts is
>>> undefined will itself be undefined..." However, in practice I see
>>> NullPointerExceptions when such expressions are evaluated. For example:
>>>
>>> inv inParamControlDisabled: let opposite : Bindable =
>>> getInboundValueBinding()->first().getOppositeEndpoint(self).target in
>>> enabled.value and opposite.oclIsKindOf(Parameter) implies
>>> opposite.oclAsType(Parameter).inout <> InOutType::IN
>>>
>>> throws NPE if getInboundValueBinding() returns an empty list, apparently
>>> as a result of attempting to using Java reflection APIs to invoke the
>>> getOppositeEndpoint() method on a null reference. At present the only way
>>> around this is to make the OCL expressions self-null-checking, which
>>> obviously makes them more complicated than the spec. suggests they need
>>> be, less readily comprehensible and (presumably) less performant.
>>>
>>> Is my understanding of the OCL spec. flawed or is this a bug?
>>>
>>> Thanks in advance,
>>>
>>> Adrian Price
>>> Senior Architect
>>> TIBCO Software, Inc.
>
>