Issue 15978: clause 8.3.1.4 Exception needs to document the taxonomy of Exception types in QVT1.1 (qvt-rtf) Source: NASA (Dr. Nicolas F. Rouquette, nicolas.f.rouquette(at)jpl.nasa.gov) Nature: Uncategorized Issue Severity: Summary: In particular, this taxonomy should explicitly include the AssertionFailed exception type that clause 8.2.2.20 refers to for an AssertExp. Suggest defining a String message attribute for Exception; this would facilitate retrieving the message from a raise expression (clause 8.2.2.15) Suggest defining AssertionFailed as a subtype of Exception. Suggest defining 2 attributes in AssertionFailed corresponding to the severity and log expressions of the AssertExp (clause 8.2.2.20) Resolution: Yes. We need a toxonomy. At the root is clearly Exception and this needs no parameters. We need to introduce a derived StringException for the standard string-valued RaiseExp, and oops we need to modify the grammar to support this shorthand. The LogExp-valued AssertionFailed is another derivation of Exception; no severity since it is always fatal. Revised Text: In 8.2.2.15 RaiseExp change The notation uses the raise keyword with the exception name as body. The exceptions can be provided as simple strings. In that case the implicit referred exception is the user Exception defined in the QVT standard library and the string is the argument of the raise expression. myproperty := self.something default raise "ProblemHere"; to The notation uses the raise keyword followed by the exception type name and arguments for one of the expression type name constructors. myproperty := self.something default raise StringException("ProblemHere"); The exceptions can be provided as simple strings. This is a shorthand for raising a StringException with the string as the constructor argument myproperty := self.something default raise "ProblemHere"; Following 8.3.1.4 Exception add additional sub-sub-sub-sections <new sub-sub-sub-section> StringException The StringException supports the simple string-valued shorthand of a RaiseExp. Superclasses Exception Constructor StringException(reason : String) reason : String [1] The reason provided on construction. <new sub-sub-sub-section> AssertionFailed The AssertionFailed exception supports a fatal AssertExp. Superclasses Exception Constructor AssertionFailed(reason : LogExp) Attributes reason : LogExp [1] The reason provided on construction. In 8.4.7 change <raise_exp> ::= 'raise' <scoped_identifier> ('(' <arg_list>? ')')? to <raise_exp> ::= 'raise' <scoped_identifier> ('(' <arg_list>? ')')? | 'raise' <STRING> Actions taken: January 21, 2011: received issue July 15, 2014: closed issue Discussion: End of Annotations:===== m: "Rouquette, Nicolas F (313K)" To: "issues@omg.org" CC: "qvt-rtf@omg.org" Date: Fri, 21 Jan 2011 07:34:27 -0800 Subject: QVT1.1, try/catch exception notation & Exception types Thread-Topic: QVT1.1, try/catch exception notation & Exception types Thread-Index: Acu5gLCeJY3Kjaz9RnehG25Mrujbww== Accept-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US X-Source-IP: altvirehtstap02.jpl.nasa.gov [128.149.137.73] X-Source-Sender: nicolas.f.rouquette@jpl.nasa.gov X-AUTH: Authorized X-MIME-Autoconverted: from quoted-printable to 8bit by amethyst.omg.org id p0LFYDXU018642 There are 2 issues in QVT 1.1 2) clause 8.3.1.4 Exception needs to document the taxonomy of Exception types in QVT1.1 In particular, this taxonomy should explicitly include the AssertionFailed exception type that clause 8.2.2.20 refers to for an AssertExp. Suggest defining a String message attribute for Exception; this would facilitate retrieving the message from a raise expression (clause 8.2.2.15) Suggest defining AssertionFailed as a subtype of Exception. Suggest defining 2 attributes in AssertionFailed corresponding to the severity and log expressions of the AssertExp (clause 8.2.2.20) - Nicolas From: "Rouquette, Nicolas F (313K)" To: Ed Willink CC: "issues@omg.org" , "qvt-rtf@omg.org" Date: Fri, 21 Jan 2011 10:36:23 -0800 Subject: Re: QVT1.1, try/catch exception notation & Exception types Thread-Topic: QVT1.1, try/catch exception notation & Exception types Thread-Index: Acu5mhr0WiyuJmMxSLyp0SSovNTrog== Accept-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US X-Source-IP: altvirehtstap01.jpl.nasa.gov [128.149.137.72] X-Source-Sender: nicolas.f.rouquette@jpl.nasa.gov X-AUTH: Authorized X-MIME-Autoconverted: from quoted-printable to 8bit by amethyst.omg.org id p0LIaH4I012384 Ed, OCL's and QVTo's exception systems serve different purposes, they are not inconsistent with one another but could be better integrated. OCL's exception system is oriented for values; not control flow as is QVTo's exception system. QVTo's assert, raise and try/catch expressions are mechanisms for organizing control flow in terms of exceptions. Integrating the two systems is possible in QVTo, e.g.: assert fatal (x.oclIsInvalid()); if (x.oclIsInvallid()) then raise '...' endif; x.oclIsInvalid() implies raise '...'; Each of these alternatives results in a QVTo exception of some kind, i.e., AssertionFailed in the first case. - Nicolas. On Jan 21, 2011, at 9:57 AM, Ed Willink wrote: > Hi > > The use of exceptions in QVTo is inconsistent with OCL, where 'invalid' > is 'the' exceptional value. In practice implementations may have > multiple equivalent 'invalid' objects with secret values in order to > propagate an exception or invalidity reason. > > A more coherent design might have OCL explicitly endorsing auxiliary > values for 'invalid' so that QVTo exception catching could be a value > type filtering action. > > Regards > > Ed Willink > > On 21/01/2011 15:34, Rouquette, Nicolas F (313K) wrote: >> There are 2 issues in QVT 1.1. >> >> 1) Current abstract/concrete syntax for try/catch in clauses 8.2.2.13& 8.2..2.14 lacks support for retrieving the exception caught. >> >> That is, QVT1.1 is currently limited to the following style of try/catch logic: >> >> try { >> // ... >> } except (Exception) { >> // there is no syntax to bind the actual exception caught to a variable or to retrieve it in an except expression. >> }; >> >> One possibility would be to introduce a variable in the catch expression (clause 8.2.2.14), e.g.: >> >> try { >> // ... >> } except (Exception e) { >> // do something with the exception caught: e >> }; >> >> or: >> >> try { >> // ... >> } except (Exception1 e1, Exception2 e2) { >> // do something with the exception caught: e1 or e2 >> }; >> >> 2) clause 8.3.1.4 Exception needs to document the taxonomy of Exception types in QVT1.1 >> >> In particular, this taxonomy should explicitly include the AssertionFailed exception type that clause 8.2.2.20 refers to for an AssertExp. >> Suggest defining a String message attribute for Exception; this would facilitate retrieving the message from a raise expression (clause 8.2.2.15) >> Suggest defining AssertionFailed as a subtype of Exception. >> Suggest defining 2 attributes in AssertionFailed corresponding to the severity and log expressions of the AssertExp (clause 8.2.2.20) >> >> - Nicolas. >> >> >> >> ----- >> No virus found in this message. >> Checked by AVG - www.avg.com >> Version: 10.0.1191 / Virus Database: 1435/3393 - Release Date: 01/20/11 >> >> >> Subject: RE: QVT1.1, try/catch exception notation & Exception types Date: Mon, 24 Jan 2011 10:45:01 +0100 X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: QVT1.1, try/catch exception notation & Exception types Thread-Index: Acu5mhr0WiyuJmMxSLyp0SSovNTrogCDX7JQ From: To: , Cc: X-OriginalArrivalTime: 24 Jan 2011 09:45:02.0247 (UTC) FILETIME=[5F46D370:01CBBBAB] X-MIME-Autoconverted: from quoted-printable to 8bit by amethyst.omg.org id p0O9iUV2022586 Hi, >>> OCL's and QVTo's exception systems serve different purposes, >>> they are not inconsistent with one another but could be better >>> integrated. Agree. Regarding the resolution proposal, I'm fine with it. But maybe the notation should be: try { // ... } except (e1:Exception1, e2:Exception2) { // do something with the exception caught: e1 or e2 }; } to follow existing UML var declaration conventions. -Mariano -----Message d'origine----- De : Rouquette, Nicolas F (313K) [mailto:nicolas.f.rouquette@jpl.nasa.gov] Envoyé : vendredi 21 janvier 2011 19:36 À : Ed Willink Cc : issues@omg.org; qvt-rtf@omg.org Objet : Re: QVT1.1, try/catch exception notation & Exception types Ed, OCL's and QVTo's exception systems serve different purposes, they are not inconsistent with one another but could be better integrated. OCL's exception system is oriented for values; not control flow as is QVTo's exception system. QVTo's assert, raise and try/catch expressions are mechanisms for organizing control flow in terms of exceptions. Integrating the two systems is possible in QVTo, e.g.: assert fatal (x.oclIsInvalid()); if (x.oclIsInvallid()) then raise '...' endif; x.oclIsInvalid() implies raise '...'; Each of these alternatives results in a QVTo exception of some kind, i.e., AssertionFailed in the first case. - Nicolas. On Jan 21, 2011, at 9:57 AM, Ed Willink wrote: > Hi > > The use of exceptions in QVTo is inconsistent with OCL, where 'invalid' > is 'the' exceptional value. In practice implementations may have > multiple equivalent 'invalid' objects with secret values in order to > propagate an exception or invalidity reason. > > A more coherent design might have OCL explicitly endorsing auxiliary > values for 'invalid' so that QVTo exception catching could be a value > type filtering action. > > Regards > > Ed Willink > > On 21/01/2011 15:34, Rouquette, Nicolas F (313K) wrote: >> There are 2 issues in QVT 1.1. >> >> 1) Current abstract/concrete syntax for try/catch in clauses 8.2.2.13& 8.2..2.14 lacks support for retrieving the exception caught. >> >> That is, QVT1.1 is currently limited to the following style of try/catch logic: >> >> try { >> // ... >> } except (Exception) { >> // there is no syntax to bind the actual exception caught to a variable or to retrieve it in an except expression. >> }; >> >> One possibility would be to introduce a variable in the catch expression (clause 8.2.2.14), e.g.: >> >> try { >> // ... >> } except (Exception e) { >> // do something with the exception caught: e }; >> >> or: >> >> try { >> // ... >> } except (Exception1 e1, Exception2 e2) { >> // do something with the exception caught: e1 or e2 }; >> >> 2) clause 8.3.1.4 Exception needs to document the taxonomy of >> Exception types in QVT1.1 >> >> In particular, this taxonomy should explicitly include the AssertionFailed exception type that clause 8.2.2.20 refers to for an AssertExp. >> Suggest defining a String message attribute for Exception; this would >> facilitate retrieving the message from a raise expression (clause 8.2.2.15) Suggest defining AssertionFailed as a subtype of Exception. >> Suggest defining 2 attributes in AssertionFailed corresponding to the >> severity and log expressions of the AssertExp (clause 8.2.2.20) >> >> - Nicolas. >> >> >> >> ----- >> No virus found in this message. >> Checked by AVG - www.avg.com >> Version: 10.0.1191 / Virus Database: 1435/3393 - Release Date: >> 01/20/11 >> >> >> X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvsEAH9XOU3Unw4T/2dsb2JhbACkZXO9SIVQBA Date: Fri, 21 Jan 2011 17:57:35 +0000 From: Ed Willink User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.0; en-GB; rv:1.9.2.13) Gecko/20101207 Thunderbird/3.1.7 To: "Rouquette, Nicolas F (313K)" CC: "issues@omg.org" , "qvt-rtf@omg.org" Subject: Re: QVT1.1, try/catch exception notation & Exception types Hi The use of exceptions in QVTo is inconsistent with OCL, where 'invalid' is 'the' exceptional value. In practice implementations may have multiple equivalent 'invalid' objects with secret values in order to propagate an exception or invalidity reason. A more coherent design might have OCL explicitly endorsing auxiliary values for 'invalid' so that QVTo exception catching could be a value type filtering action. Regards Ed Willink On 21/01/2011 15:34, Rouquette, Nicolas F (313K) wrote: There are 2 issues in QVT 1.1. 1) Current abstract/concrete syntax for try/catch in clauses 8.2.2.13& 8.2..2.14 lacks support for retrieving the exception caught. That is, QVT1.1 is currently limited to the following style of try/catch logic: try { // ... } except (Exception) { // there is no syntax to bind the actual exception caught to a variable or to retrieve it in an except expression. }; One possibility would be to introduce a variable in the catch expression (clause 8.2.2.14), e.g.: try { // ... } except (Exception e) { // do something with the exception caught: e }; or: try { // ... } except (Exception1 e1, Exception2 e2) { // do something with the exception caught: e1 or e2 }; 2) clause 8.3.1.4 Exception needs to document the taxonomy of Exception types in QVT1.1 In particular, this taxonomy should explicitly include the AssertionFailed exception type that clause 8.2.2.20 refers to for an AssertExp. Suggest defining a String message attribute for Exception; this would facilitate retrieving the message from a raise expression (clause 8.2.2.15) Suggest defining AssertionFailed as a subtype of Exception. Suggest defining 2 attributes in AssertionFailed corresponding to the severity and log expressions of the AssertExp (clause 8.2.2.20) - Nicolas. ----- No virus found in this message. Checked by AVG - www.avg.com Version: 10.0.1191 / Virus Database: 1435/3393 - Release Date: 01/20/11 .