Eclipse Community Forums
Forum Search:

Search      Help    Register    Login    Home
Home » Modeling » OCL » Bug in OCLAbstractAnalyzer
Bug in OCLAbstractAnalyzer [message #56033] Fri, 16 May 2008 11:18 Go to next message
Adolfo Sanchez-Barbudo Herrera is currently offline Adolfo Sanchez-Barbudo Herrera
Messages: 253
Registered: July 2009
Senior Member
Hi Christian,

I have detected a problem when resolving a featureCallExp which will
involve an implicit collect iterator.

Think about getting a collection of names from a collection of Classes.
for example the following expression should be useful

aCollectionOfClasses.name

because its implicit translated to

aCollectionOfClasses->collect(i | i.name);

If the name of a property doesn't exist, an NPE is thrown when trying to
create the implicit collect.

/*
* If the source type is a collection, then need there is an implicit
COLLECT operator.
* Note that this rule is not called after "->".
*/
if ((source != null) && source.getType() instanceof CollectionType) {
astNode = createImplicitCollect(
source,
(FeatureCallExp<C>) astNode,
env,
simpleNameCS);
}

The problem is that dummyInvalidLiteralExp is created if the feature is
not found, so a classCastException is thrown when doing the the typeCasting.

It seems to be a regression bug.

An extra question for you, why do you mention that 'Note that this rule
is not called after "->"'. How should it be interpreted the following
featureCallExp ?

aCollectonOfClasess->name

Cheers,
Adolfo.
Re: Bug in OCLAbstractAnalyzer [message #56063 is a reply to message #56033] Fri, 16 May 2008 19:01 Go to previous messageGo to next message
Adolfo Sanchez-Barbudo Herrera is currently offline Adolfo Sanchez-Barbudo Herrera
Messages: 253
Registered: July 2009
Senior Member
Hi Christian

Confirmed that It's a bug...

The OCL crash, if you access an in-existent property of a multivalued
property (or of a collection).

This should be the resolved bug which caused the regression:

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

I'll raise a bugzilla.

Cheers,
Adolfo.


Adolfo Sánchez-Barbudo Herrera escribió:
> Hi Christian,
>
> I have detected a problem when resolving a featureCallExp which will
> involve an implicit collect iterator.
>
> Think about getting a collection of names from a collection of Classes.
> for example the following expression should be useful
>
> aCollectionOfClasses.name
>
> because its implicit translated to
>
> aCollectionOfClasses->collect(i | i.name);
>
> If the name of a property doesn't exist, an NPE is thrown when trying to
> create the implicit collect.
>
> /*
> * If the source type is a collection, then need there is an implicit
> COLLECT operator.
> * Note that this rule is not called after "->".
> */
> if ((source != null) && source.getType() instanceof CollectionType) {
> astNode = createImplicitCollect(
> source,
> (FeatureCallExp<C>) astNode,
> env,
> simpleNameCS);
> }
>
> The problem is that dummyInvalidLiteralExp is created if the feature is
> not found, so a classCastException is thrown when doing the the
> typeCasting.
>
> It seems to be a regression bug.
>
> An extra question for you, why do you mention that 'Note that this rule
> is not called after "->"'. How should it be interpreted the following
> featureCallExp ?
>
> aCollectonOfClasess->name
>
> Cheers,
> Adolfo.
Re: Bug in OCLAbstractAnalyzer [message #56089 is a reply to message #56033] Sun, 18 May 2008 18:06 Go to previous message
Eclipse User
Originally posted by: cdamus.zeligsoft.com

Hi, Adolfo,

I have resolved the bug. Note that, when you find bugs, you can just
raise them in bugzilla and save yourself some typing :-)

I don't think I am the author of the "note that this rule ..."
comment, but what it means is that the implicit collect iterator is
only created for dot-navigation ('.' operator). The arrow is applied
to values that already are collections (or are coerced to singleton
sets) so there is no collecting to do.

Note, also, that your example

aCollectionOfClases->name

is ill-formed OCL because 'name' is not an attribute of the collection
type. The arrow operator exclusively indicates features of
collections (which is why the rules for scalar coercion and implicit
collect are feasible). Currently, OCL only defines operations for
collection types, no attributes.

Cheers,

Christian


On Friday 05-16-2008 (07:18), Adolfo Sánchez-Barbudo Herrera wrote:
> Hi Christian,

> I have detected a problem when resolving a featureCallExp which will
> involve an implicit collect iterator.

> Think about getting a collection of names from a collection of
> Classes. for example the following expression should be useful

> aCollectionOfClasses.name

> because its implicit translated to

> aCollectionOfClasses->collect(i | i.name);

> If the name of a property doesn't exist, an NPE is thrown when
> trying to create the implicit collect.

> /*
> * If the source type is a collection, then need there is an implicit
> COLLECT operator.
> * Note that this rule is not called after "->".
> */
> if ((source != null) && source.getType() instanceof CollectionType)
> { astNode = createImplicitCollect(
> source,
> (FeatureCallExp<C>) astNode,
> env,
> simpleNameCS);
> }

> The problem is that dummyInvalidLiteralExp is created if the
> feature is not found, so a classCastException is thrown when doing
> the the
> typeCasting.

> It seems to be a regression bug.

> An extra question for you, why do you mention that 'Note that this
> rule is not called after "->"'. How should it be interpreted the
> following featureCallExp ?

> aCollectonOfClasess->name

> Cheers,
> Adolfo.


--

I'm trying a new usenet client for Mac, Nemo OS X.
You can download it at http://www.malcom-mac.com/nemo
Previous Topic:implementation for checking invalid select expressions
Next Topic:Comparison operators
Goto Forum:
  


Current Time: Wed Oct 22 15:34:56 GMT 2014

Powered by FUDForum. Page generated in 0.10696 seconds
.:: Contact :: Home ::.

Powered by: FUDforum 3.0.2.
Copyright ©2001-2010 FUDforum Bulletin Board Software