Re: OCL: dealing with exceptions



Date view Thread view Subject view Author view Attachment view

From: Anneke Kleppe (A.Kleppe@klasse.nl)
Date: Thu 30 May 2002 - 09:09:44 BST


Brian,

Coming monday we expect to see a number (three or more) of submissions for 
the UML 2.0 and for the MOF 2.0. Three weeks later there will be an OMG 
meeting during which decisions will be made on how to proceed. If the 
groups decide not to cooperate, a later OMG meeting will vote on the 
submissions. So there is much uncertain at the moment.

Anneke

At 06:24 AM 29-05-2002 -0500, you wrote:
>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".
>
>
>
>
>
>
>
>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

Date view Thread view Subject view Author view Attachment view