Eclipse Community Forums: OCL » [OCLInEcore] Change default error messages

Help

Home

Home » Modeling » OCL » [OCLInEcore] Change default error messages

Show: Today's Messages :: Show Polls :: Message Navigator

[OCLInEcore] Change default error messages [message #552198]

Wed, 11 August 2010 08:17

Toñi Reina

Messages: 209
Registered: July 2009

Senior Member

Hi all,

finally, I've been able to use OCLInEcore and Eugenia without any
problema. My question is related to the message shown when the editor
validate the constraint. The default message is: The <nameofConstraint>
constraint is violated on <model element>.

I'd like to customize this message in order to explain the problem
better. Is there any way to do this with [OCLInEcore]?

Thanks in advanced,
Toñi

Report message to a moderator

Re: [OCLInEcore] Change default error messages [message #552206 is a reply to message #552198]

Wed, 11 August 2010 08:48

Ed Willink

Messages: 7655
Registered: July 2009

Senior Member

Hi Toni

No messages are not customisable; well I'm sure they are if you modify
enough code intelligently. But it is a very sensible request.

I've been considering suggesting a change to the Complete OCL grammar
for e.g.

inv nameOfConstraint: bodyOfConstraint

to allow:

inv nameOfConstraint(reason): bodyOfConstraint

where 'reason' is a string-valued expression that an implementation may
choose to evaluate to explain the constraint failure.

OCLinEcore would of course then have a corresponding syntax.

I'll submit the OMG issue now.

This should then make OCL-based validation in the editors and other
tools user-friendly.

Regards

Ed Willink

On 11/08/2010 09:17, Toñi Reina Quintero wrote:
> Hi all,
>
> finally, I've been able to use OCLInEcore and Eugenia without any
> problema. My question is related to the message shown when the editor
> validate the constraint. The default message is: The <nameofConstraint>
> constraint is violated on <model element>.
>
> I'd like to customize this message in order to explain the problem
> better. Is there any way to do this with [OCLInEcore]?
>
> Thanks in advanced,
> Toñi

Report message to a moderator

Re: [OCLInEcore] Change default error messages [message #552213 is a reply to message #552206]

Wed, 11 August 2010 09:58

Toñi Reina

Messages: 209
Registered: July 2009

Senior Member

Ok, Ed,

thanks for the info.

El 11/08/2010 10:48, Ed Willink escribió:
> Hi Toni
>
> No messages are not customisable; well I'm sure they are if you modify
> enough code intelligently. But it is a very sensible request.
>
> I've been considering suggesting a change to the Complete OCL grammar
> for e.g.
>
> inv nameOfConstraint: bodyOfConstraint
>
> to allow:
>
> inv nameOfConstraint(reason): bodyOfConstraint
>
> where 'reason' is a string-valued expression that an implementation may
> choose to evaluate to explain the constraint failure.
>
> OCLinEcore would of course then have a corresponding syntax.
>
> I'll submit the OMG issue now.
>
> This should then make OCL-based validation in the editors and other
> tools user-friendly.
>
> Regards
>
> Ed Willink
>
>
>
> On 11/08/2010 09:17, Toñi Reina Quintero wrote:
>> Hi all,
>>
>> finally, I've been able to use OCLInEcore and Eugenia without any
>> problema. My question is related to the message shown when the editor
>> validate the constraint. The default message is: The <nameofConstraint>
>> constraint is violated on <model element>.
>>
>> I'd like to customize this message in order to explain the problem
>> better. Is there any way to do this with [OCLInEcore]?
>>
>> Thanks in advanced,
>> Toñi
>

Report message to a moderator

Re: [OCLInEcore] Change default error messages [message #556535 is a reply to message #552198]

Wed, 01 September 2010 16:47

Simon harrer

Messages: 25
Registered: August 2010

Junior Member

Hi Toni,

could you help me out using Eugenia und OCLinEcore together? I thougth, i had to use emfatic for this. Is it possible to use Eugenia only with OCLinEcore?

Best regards,
Simon

Report message to a moderator

Re: [OCLInEcore] Change default error messages [message #632664 is a reply to message #556535]

Wed, 13 October 2010 19:24

Jos Warmer

Messages: 114
Registered: October 2010

Senior Member

As an example of how to do this, you might want to take a look at Check (from the Itemis guys), which has a flexible way to get exactly the error message you want.

Jos

Report message to a moderator

Re: [OCLInEcore] Change default error messages [message #632730 is a reply to message #632664]

Thu, 14 October 2010 05:40

Ed Willink

Messages: 7655
Registered: July 2009

Senior Member

Hi Jos

Work in progress uses OCL for the OCL validation and implements issue 15412:

"Suggest add an optional argument to the (not-optional) constraint name.
e.g.

inv ConstraintName('Unable to find ' + self.target.name): ..."

I am keen to share as much OCL as possible from the OCL spec in order to
debug the spec. Xtext will already execute OCL-based validation.

Regards

Ed

On 13/10/2010 20:24, Jos Warmer wrote:
> As an example of how to do this, you might want to take a look at Check
> (from the Itemis guys), which has a flexible way to get exactly the
> error message you want.
>
> Jos

Report message to a moderator

Re: [OCLInEcore] Change default error messages [message #633214 is a reply to message #632730]

Fri, 15 October 2010 16:40

Jos Warmer

Messages: 114
Registered: October 2010

Senior Member

In Check the error message is simply an OCL expression of type String. This allows full access to information from the model, not just one element. You could write

inv ConstraintName('Unable to find ' + self.target.name + ' for ' + self.kindName + ' in model ' + self.model.name):
   <<the invariant in OCL>>

I think this just a logical extension of what is proposed already. And it only uses OCL, nothing else as you rightfully want.

Report message to a moderator

Re: [OCLInEcore] Change default error messages [message #633294 is a reply to message #633214]

Sat, 16 October 2010 05:13

Ed Willink

Messages: 7655
Registered: July 2009

Senior Member

Hi Jos

I'm not fond of Check or Xpand, since they use a hybrid Java-like
OCL-like language.

I can see an argument for a different OCL syntax that fixes the "->"
surprise, but not one that fails to realize other important OCL
characreristics.

My challenge is to make MDT/OCL sufficiently robust and re-useable to
encourage non MDT/OCL Eclipse projects to migrate. Making the Standard
Library model-driven may allow a Check syntax to use MDT/OCL tooling.

A Complete OCL document should provide similar capabilities to Check in
standard form; we just need to solve the problme of how a tool using a
model with an associated meta-model discovers the complementing Complete
OCL. For embedded OCLinEcore this is all much easier.

Your example of an arbitrary String expression was exactly what I'd
intended. My only uncertainty is whether the string expression is
evaluated in the scope of the declaration or the scope of the failed
invariant, which could allow re-use of already computed let variables
and prevailing iterator content. If 'invalid' is relaxed to behave as,
rather than be, a singleton, then 'invalid' (just like an exception)
could carry a reason and/or exception trace from the point of creation
of an invalid value to the point of analysis of that invalid value.

Regards

Ed Willink

On 15/10/2010 17:40, Jos Warmer wrote:
> In Check the error message is simply an OCL expression of type String.
> This allows full access to information from the model, not just one
> element. You could write
>
> inv ConstraintName('Unable to find ' + self.target.name + ' for ' +
> self.kindName + ' in model ' + self.model.name):
> <<the invariant in OCL>>
>
> I think this just a logical extension of what is proposed already. And
> it only uses OCL, nothing else as you rightfully want.

Report message to a moderator

Previous Topic:	[OCL-Java] java.lang.NoClassDefFoundError: lpg/runtime/RuleAction
Next Topic:	[OCL-ECORE-JAVA] OCL Queries on Ecore model from Java code.

Goto Forum:

-=] Back to Top [=-

[ Syndicate this forum (XML) ] [

]

Current Time: Tue Apr 23 16:36:31 GMT 2024

.:: Contact :: Home ::.

Breadcrumbs

Sign up to our Newsletter