UMLIdResolver::getStaticTypeOf(Object value) hides Parser Exceptions

[eclipse-ocl-bot]

| --- | --- | | Bugzilla Link | 482264 | | Status | NEW | | Importance | P3 normal | | Reported | Nov 16, 2015 05:56 EDT | | Modified | Nov 16, 2015 08:24 EDT | | Version | 6.0.0 | | See also | 482143 | | Reporter | Yves BERNARD |

Description

The body of UMLIdResolver::getStaticTypeOf(Object value) contains the folowing code:

    if (value instanceof org.eclipse.uml2.uml.Element) {\
        try {               // FIXME Find a more efficient way to ensure Profiles are imported and applied\
            org.eclipse.uml2.uml.Element umlElement = (org.eclipse.uml2.uml.Element)value;\
            metamodelManager.getASOf(Element.class, umlElement); // Needed by test_stereotypes_Bug431638\
            EClass umlEClass = umlElement.eClass();\
            org.eclipse.ocl.pivot.Class umlAStype = metamodelManager.getASOf(org.eclipse.ocl.pivot.Class.class, umlEClass);\
            if (umlAStype != null) {\
                return umlAStype;\
            }\
            \
        } catch (ParserException e) {\
            // TODO Auto-generated catch block\

// e.printStackTrace();\ }

Since the e.printStackTrace() instruction is a comment, any Parser exception is simply hidden, leading to an hardly understandable behavior becauseno

clue is given that such an exception occurs.

[eclipse-ocl-bot]

By Ed Willink on Nov 16, 2015 06:30

I suspect the commenting out dates back to when UML2AS occurred much more eagerly and gave quite a few errors on bad OCL embedded in the UML metamodel.

Changing it to throw new UnsupportedOperationException(e); gives no test failures, so the need for the commenting out seems to have gone.

But

// FIXME Find a more efficient way to ensure Profiles are imported and applied

suggests that the code deserves a revisit and

metamodelManager.getASOf(Element.class, umlElement); // Needed by test_stereotypes_Bug431638

looks suspiciously like the problem in Bug 482143.

So well worth a revisit and a decent mechanism to propagate the parser exception to the caller. Unfortunately it's a nested resource problem, so the best that can be done locally is to accumulate a Resource.errors and then be more diligent about looking for deep errors in calling code.

Do you happen to recall how you 'failed to observe' the error? I presume it's a profile with a syntax error in an invariant, but how do you execute it?

[eclipse-ocl-bot]

By Yves BERNARD on Nov 16, 2015 06:46

Created attachment 257964 Custom profile

:notepad_spiral: OTI.profile.uml

[eclipse-ocl-bot]

By Yves BERNARD on Nov 16, 2015 08:24

Ed,

The error was found by migrating a custom OCL evaluation console to OCL 6.0. This console is able to use an extended stdlib plus a set of user defined (ocl) operations specified in an .ocl file.

The error appears when the context is set to an element owned in a model which has a custom profile applied. However, this profile is very simple since it contains only two stereotypes (of which a dummy one used nowhere and created for test purpose), none of them owning constraints (see attached).

There are other things that don't work properly since I migrated the code, including a (big) memory leak, but I guess that they probably come from error I made when I modified the code to use the new API. I'm currently investigating.

Yves