Issue 15977: abstract/concrete syntax for try/catch in clauses 8.2.2.13 & 8.2.2.14 lacks support for retrieving the exception caught (qvt-rtf)
Source: NASA (Dr. Nicolas F. Rouquette, nicolas.f.rouquette(at)jpl.nasa.gov)
Nature: Uncategorized Issue
Severity: 
Summary: 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
};


Resolution: Yes. Unuseable caught exceptions are clearly of limited utility.
There can only be one exception variable name for many exception types; what is its type? Cannot be
any of the listed types so it will have to be the common super type. Introduce a new exceptionVariable.
Of course the lower bound on the exception type should be 1. If a catch all is required then the type
can be Exception. If a finally is required then we need a wrapper or specification enhancement.
Revised Text: In 8.2.2.13 TryExp add
The exceptClauses are searched in order to select the first exceptClause that provides an exception type to
which the raised exception conforms. If an exceptClause is selected, its body is executed.
In 8.2.2.14 CatchExp add
The caught expression may be accessed in the body expression using the exceptionVariable whose apparent
(static) type is the most derived common super type of all catchable exception types. In 8.2.2.14 CatchExp and the QVT 1.1 models add
exceptionVariable : String [0..1]
The variable through which the caught exception may be accessed.
In 8.2.2.14 CatchExp and the QVT 1.1 models change
exception: Type [*] {ordered}
to
exception: Type [+] {ordered}
In 8.4.7 change
<except> ::= 'except' '(' <scoped_identifier_list> ')' <expression_block>
to
<except> ::= 'except' '(' [<identifier> ':'] <scoped_identifier>
[',' <scoped_identifier>]* ')' <expression_block>
Actions taken:
January 21, 2011: received issue
July 15, 2014: closed issue
Discussion: 

End of Annotations:=====

m: "Rouquette, Nicolas F (313K)" <nicolas.f.rouquette@jpl.nasa.gov>
To: "issues@omg.org" <issues@omg.org>
CC: "qvt-rtf@omg.org" <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.


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
};