Re: OCL: dealing with exceptions



Date view Thread view Subject view Author view Attachment view

From: Brian Smith (brian-l-smith@uiowa.edu)
Date: Wed 29 May 2002 - 12:24:07 BST


Anneke,

I don't know where I can find the status for UML 2.0 and MOF 2.0. My 
impression was that there were a few "coalitions" of submitters for UML 
2.0 including the "2u" and "u2" groups. Are the various groups working 
together now? It seems that they are still working on seperate proposals 
because each group occasionally posts an updated version of their draft. 
Having seperate proposals makes it very difficult to follow along 
(especially considering the documents are getting pretty big).

I appreciate that adding exception-raising capabilities is not easy. 
Also, adding the ability for OCL to specify the raising of exceptions 
adds some preasure to allow OCL to have mechanisms to handle/recover 
from exceptions ("if this operation raises XXX, then return YYY else 
....").

- Brian

Anneke Kleppe wrote:

> I understand the wish the express that exceptions are raised and under 
> which conditions that occurs, and I'll do my best to get it in OCL. 
> But again, we can not specify such a construct until the UML 2.0 and 
> MOF 2.0 Core packages are stabilized. It makes a lot of difference 
> whether an exception is considered to be a classifier or not, and what 
> raising an exception means in terms of the metamodel (is a new 
> Exception object created, or are the attributes of an existing 
> Exception object changed, is it an operation call on a metamodel 
> object?), etc. etc.
>
> I personaly find it very frustrating to have to wait so long before 
> the core concepts are finalized, specially because the OCL 2.0 is 
> finished but for the parts that need to be aligned. But there's 
> nothing we can do. Maybe next week we'll know more.
>
> Anneke
>
> At 12:08 PM 28-05-2002 -0500, you wrote:
>
>> Anneke Kleppe wrote:
>>
>>> The current status of OCL 2.0 is that it is aligned with the UML 
>>> 1.4. As soon as the UML 2.0 submissions stabilize, we will align OCL 
>>> 2.0 with UML 2.0. As the core of the UML 2.0 is to be the core of 
>>> the MOF 2.0 also, the alignment of OCL with MOF follows.
>>>
>>> Now to answer your question: no there is currently no explicit 
>>> support in OCL 2.0 for these MOF exceptions. There might be later 
>>> on, if during the alignment this proves to be an important issue.
>>>
>>> BTW, you say you are expecting it, but there have not been any 
>>> requests to the OCL submission team to include this. Please tell us, 
>>> if you want something in. We are only human, you know. :-)
>>
>>
>> Well, I think it seems useful to be able to specify directly, in the 
>> postcondition for an operation, what exceptions will be thrown under 
>> what circumstances. In particular, I think that you would want to be 
>> able to type-check something like this:
>>    context Bank:deposit(x : int)
>>    post: if x > 0 then balance = balance@pre + x else raised 
>> DepositException end if
>>
>> The type-checker would type this postcondition as "boolean" since, if 
>> it returns anything at all, it will return a boolean (like in ML). 
>> Your examples type-check to boolean too. But, what if you want to say 
>> this (admittedly, a contrived example):
>>
>>    context Bank::deposit(x : int)
>>    post: let with-interest = if x >= 0 then x * sqrt(x) else raised 
>> DepositException end if in
>>            balance = balance@pre + with-interest
>>
>> Now, interest(x) has to type-check to a rational number. But, it 
>> isn't clear to me how, using any approach, how I can express 
>> with-interest in a type-safe manner.
>>
>> Even without the above, the examples cited still seem very awkward to 
>> use in practice, compared to something like "raised" above. I think 
>> users of UML/OCL would want a "raised" facility in OCL, especially 
>> for languages like Java where exceptions are as much a part of the 
>> postconditions as normal returns (i.e. you want to distingush between 
>> "undefined behavior" and "exception XXX raised"). Perhaps the 
>> specifics of such a construct are difficult to specify though?
>>
>> Thanks,
>> Brian
>>
>>
>>
>>
>>
>> To remove yourself from this list please mail 
>> puml-list-request@cs.york.ac.uk
>> with a message containing the word "unsubscribe".
>>
>
> Klasse Objecten
> Chalonhof 153
> NL - 3762 CT Soest
> The Netherlands
> voice: +31(0)35-6037646
> fax: +31(0)35-6037647
> http://www.klasse.nl
>
>
>
>
> To remove yourself from this list please mail 
> puml-list-request@cs.york.ac.uk
> with a message containing the word "unsubscribe".

Date view Thread view Subject view Author view Attachment view