Community
Participate
Working Groups
OMG QVT1.1 RTF issue #15977: 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 }; ============================================================= OMG QVT1.1 RTF issue #15978: 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)
(In reply to Nicolas Rouquette from comment #0) > } except (Exception e) { Obviously should be } except (e : Exception) { > } except (Exception1 e1, Exception2 e2) { Probably should be } except (e Exception1, Exception2) { with e being the common super type of all enumerated types. It doesn't make sense to mave multiple variables. > > ============================================================= > Suggest defining a String message attribute for Exception; this would > facilitate retrieving the message from a raise expression (clause 8.2.2.15) ?? nested Exception too for stack traces
(In reply to Ed Willink from comment #1) > (In reply to Nicolas Rouquette from comment #0) > > } except (Exception e) { > > Obviously should be > > } except (e : Exception) { > > > } except (Exception1 e1, Exception2 e2) { > > Probably should be > > } except (e Exception1, Exception2) { Agreed. Syntax should be } except (e: Exception1, Exception2) { > > with e being the common super type of all enumerated types. > > It doesn't make sense to mave multiple variables. Also "catch all" syntax (empty exception list) should be allowed } except () { > > > > > ============================================================= > > Suggest defining a String message attribute for Exception; this would > > facilitate retrieving the message from a raise expression (clause 8.2.2.15) > > ?? nested Exception too for stack traces You meant analog of 'Throwable.initCause(Throwable cause)'? What for in QVTo? In Java this is used for exceptions' wrapping (when exception throws beyond the boundaries of the subsystem).
(In reply to Sergey Boyko from comment #2) > > ?? nested Exception too for stack traces > > You meant analog of 'Throwable.initCause(Throwable cause)'? What for in > QVTo? In Java this is used for exceptions' wrapping (when exception throws > beyond the boundaries of the subsystem). If QVTo is to chase Java, then nested exceptions seem natural. However Eclipse QVTo has worked fine for years without exceptions. I find introduction of exceptions contrary to the spirit of OCL where exceptions are passed as invalid values. I would certainly like to see a strongly motivating use case before changing the currently unimplementable specification.
Implemented with Bug 419299.
