| Summary: | Query invoking invalid method not diagnosed | ||
|---|---|---|---|
| Product: | [Modeling] Acceleo | Reporter: | Ed Willink <ed> |
| Component: | Core | Assignee: | Project Inbox <acceleo-inbox> |
| Status: | CLOSED FIXED | QA Contact: | |
| Severity: | normal | ||
| Priority: | P3 | CC: | stephane.begaudeau |
| Version: | 3.0.0 | ||
| Target Milestone: | --- | ||
| Hardware: | PC | ||
| OS: | Windows Vista | ||
| Whiteboard: | |||
If I launch a generator and if it calls a non existing method on a Java class, two exceptions are logged.
The first one logging the real issue:
org.eclipse.acceleo.engine.AcceleoEvaluationException: Method dosdfhStuff() doesn't exist for service org.eclipse.acceleo.module.example.uml2java.helios.common.Service.
at org.eclipse.acceleo.engine.internal.environment.AcceleoLibraryOperationVisitor.invoke(AcceleoLibraryOperationVisitor.java:944)
at org.eclipse.acceleo.engine.internal.environment.AcceleoLibraryOperationVisitor.callNonStandardOperation(AcceleoLibraryOperationVisitor.java:123)
at org.eclipse.acceleo.engine.internal.environment.AcceleoEvaluationEnvironment.callOperation(AcceleoEvaluationEnvironment.java:175)
etc...
And the second one (a warning indicating that the result of the query is null):
org.eclipse.acceleo.engine.AcceleoEvaluationException: Invalid result for expression self.invoke('org.eclipse.acceleo.module.example.uml2java.helios.common.Service', 'dosdfhStuff()', Sequence {}) at line 4 in Module generate for query doStuff(OclAny). Last recorded value of self was org.eclipse.uml2.uml.internal.impl.ClassImpl@15bc2c5 (name: Boat, visibility: <unset>) (isLeaf: false, isAbstract: false) (isActive: false).
at generateJava.generateClass(Class)(generateJava.mtl:0)
at generateJava.generateClass(Class)(generateJava.mtl:18)
It seems that this issue has been resolved because the error is now (3.1) propagated. Marking this issue as resolved for now.
There is no diagnosis in the editor because such diagnosis would require a build of all the ".mtl" files after the edition of any Java files. It's too time consuming.
(In reply to comment #1) > There is no diagnosis in the editor because such diagnosis would require a > build of all the ".mtl" files after the edition of any Java files. It's too > time consuming. I agree that it is time consuming and I get rather irritated when the builder dies precisely this in 3.1. However within the editor itself, I see no reason why diagnostics shouldn't be reported. Validating a Java class is no different to validating an OCL call. [Looking forward to trying the fixes on SR1 RC2 - you didn't contribute to the SR1 RC1 EPP] Closing resolved bugs |
RC3 a) no diagnosis in editor b) runtime diagnosis gets lost AcceleoLibraryOperationVisitor catches a bad method at } catch (NoSuchMethodException e) { throw new AcceleoEvaluationException(AcceleoEngineMessages.getString( "AcceleoEvaluationEnvironment.NoSuchMethod", methodSignature, args[0]), e); //$NON-NLS-1$ But this fails to propagate to the caller where just a different org.eclipse.acceleo.engine.AcceleoEvaluationException: Invalid result for expression self.invokeis reported.