|
Notes |
|
|
|
|
Exceptions have no parameters. They are a special kind of message. |
|
|
|
|
|
STF discussion: in the BNF separate message and procedure storing rules. Delete storing part of messages for the Catch operation. |
|
|
|
|
|
I still don't understand the issue here at all. What's wrong with something that has been working for years? If an exception is caught, there are no parameters to be assigned, just the exception value. Therefore, storing it like a message makes more sense than storing it like a parameter list. |
|
|
|
(0012170)
|
|
Tomas Urban
|
20-06-2014 08:38
(edited on: 20-06-2014 08:39) |
|
I prepared two alternative solutions. The first one (CR6783_v1.docx) unifies the value redirect for getreply and catch so that only the simple syntax is allowed as requested in the CR.
However, since the current catch statement actually describes the extended syntax, the alternative proposal (CR6783_v1_alt.docx) changes only the BNF so that only the getreply statement uses the simplified form. Since the base proposal also affects the text of the catch operation, I am afraid that it would introduce backwards incompatibility. If the alternative proposal is taken into use instead of the base one, similar changes as in 0006736 shall be made in the syntax description of the catch operation as it still uses the same syntax for value redirect assignments on the BNF level as the receive operation (or the BNF should disallow the @decoded clause for the catch operation).
|
|
|
|
|
|
Following the previous STF discussion there should be some unification/modification of the storing rules and the first resolution may be selected. However we may think about also allowing the "previous" syntax for keeping backward compatibility, as a deprecated approach? |
|
|
|
|
|
The CR solution may need a final STF decision. |
|
|
|
|
|
Axel, pls. keep the CR at yourself until the STF decision. |
|
|
|
|
|
STF discussion: correct getreply syntax in text to be in synch with BNF and allow extended reference. Catch is in principle OK, but check consistency of the text with the BNF. Also make those changes in CR 6736 |
|
|
|
|
|
new syntax part for getreply in text (also considering CR6736_v5). |
|
|
|
|
|
Please confirm latest update following the STF discussion |
|
|
|
|
The proposed resolution fixes the problem by extending the syntactical description of the getvalue operation.
It is ready to be added to the next version of the TTCN-3 standard. Please make sure that the changes proposed in the resolution of the related CR 0006736 are not overwritten by this CR. |
|
|
|
|
|
CR6783_v1.docx (65,026) 20-06-2014 08:24