Skip to main content
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [qvto-dev] QVT 1.2 RTF Ballot 3 preview 2
Hi,


On Fri, Feb 7, 2014 at 12:00 PM, Ed Willink <ed@xxxxxxxxxxxxx> wrote:
Hi

StringException is arguable.

Why should it become mandatory for an Exception to have a String value?

To not multiply entities without necessity. An 'Exception' type is enough. Also it's widely adopted (Java, C++, etc.) that exception at least contains String argument.
 

Introducing StringException avoids a modification to an 'existing' class.

It's an addition to the existing type so not a problem at all.
 

    Regards

        Ed


On 07/02/2014 07:41, Sergey Boyko wrote:
Hi,

Ok, will raise an issue.


Also what about newly introduced StringException?  
It is definitely redundant and useless. String message attribute in Exception type is the right decision. Dedicated StringException is not needed and should be removed from the proposal.


Regards,
  Sergey.


On Fri, Feb 7, 2014 at 11:19 AM, Ed Willink <ed@xxxxxxxxxxxxx> wrote:
Hi

The QVT 1.1 EBNF is

<except> ::= 'except' '(' <scoped_identifier_list> ')' <expression_block>
<scoped_identifier_list> ::= <scoped_identifier> (',' <scoped_identifier>)*

This does not allow an empty list. The proposed QVT 1.2 EBNF does not allow an empty list either. So allowing an empty list is a new issue.

Given that the CS does not allow an empty list, the change in the AS to enforce what is required in the grammar seems sensible.

Even if a new issue relaxes the EBNF to allow a default, the AS should still expand the default in the interest of minimizing run-time/analysis complexity.

So I see no need for a further change to the resolution.

If you want to allow an empty except in the grammar, raise a new issue.

    Regards

        Ed


On 07/02/2014 05:55, Sergey Boyko wrote:
Hi Ed,

An empty 'except' statement
   try {}
   except() {};

is just shorthand for
   try {}
   except(Exception) {};

I don't see any reason why this should be prohibited. Both snippets above implement so called "catch all" semantics. In C++ such semantics has representation in concrete syntax as 'catch(...) {}'. For QVT simplicity is not of the least importance and an empty 'except' clause is good choice.
Also note that currently QVTo 1.1 defines 'CatchExp::exception: Type [*]' with unbound multiplicity. Eclipse QVTo implements that.


Regards,
  Sergey.



On Wed, Feb 5, 2014 at 9:08 PM, Ed Willink <ed@xxxxxxxxxxxxx> wrote:
Hi Sergey


Ballot 3 has only just started, so there is plenty of time for voters to consider changes. In 12526, 15977 of course you are correct about exceptionVariable, but I don't agree with an empty exception clause. Please start a new thread urgently if you want to discuss this.

    Regards

        Ed


On 05/02/2014 16:35, Sergey Boyko wrote:

QVT 1.2 Revision Task Force
Ballot 3 “Preview 1”


Issue 12526: Errors and anomalies in QVT 1.0 07-07-08 ZIP imperativeocl.ecore.

Property 'CatchExp.exceptionVariableName' is incorrect. There should be 'CatchExp.exceptionVariable : Variable {composes} [0..1]' in order to preserve type also.

Changing multiplicity of 'CatchExp.exception' from '*' to '+' is incorrect. Multiplicity for 'CatchExp.exception' should be '*' (so that empty 'except' statement is handled).


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.

First, revised text for 'CatchExp.exceptionVariable' should be:
  In 8.2.2.14 CatchExp and the QVT 1.1 models add
    exceptionVariable : Variable [0..1]

Second, revised text incorrectly alters description for 'CatchExp.exception'. It should be:
  In 8.2.2.14 CatchExp and the QVT 1.1 models change
    exception: Type [*] {ordered}

Third, EBNF for '<except>' is incorrect. It should be:
   In 8.4.7 change
     to
  <except> ::= 'except' '(' <except_type_list_opt> ')' <expression_block>
  <except> ::= 'except' '(' IDENTIFIER ':' <type_list> ')' <expression_block>
  <except_type_list_opt> -> <type_list> 
  <except_type_list_opt> ::= %empty


Regards,
  Sergey.


No virus found in this message.
Checked by AVG - www.avg.com
Version: 2014.0.4259 / Virus Database: 3684/7068 - Release Date: 02/06/14


_______________________________________________
qvto-dev mailing list
qvto-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/qvto-dev




_______________________________________________
qvto-dev mailing list
qvto-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/qvto-dev


No virus found in this message.
Checked by AVG - www.avg.com
Version: 2014.0.4259 / Virus Database: 3684/7068 - Release Date: 02/06/14



_______________________________________________
qvto-dev mailing list
qvto-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/qvto-dev


Back to the top