Try ... Catch statement in NSD

[fesch]

A long time ago Hanspeter Thöni asked me integrate a "try ... catch" statement.

The first drawing I made was this one. I never integrated them.

This issue is thus just a placeholder in order not to lose the idea ;-)

[codemanyak]

Interesting idea. Are we going to propose a new NSD standard? But seriously: The design is not so bad. It resembles a jump as well as the forced sequence into the finally block. But how should it look if try and catch block consist of instruction sequences including complex control structures themselves?

[fesch]

You are right, this first drawing omits the "blocks". Maybe, to stay with them, we could do something like this, which resembles the code structure somewhat more:

[fesch]

But anyway, that will be very funny to implement in the executor ... especially when such try-statements will include some other try-statements ...

[codemanyak]

... yep! And we shouldn't forget that the request for a throw mechanism would be raised as well, where of course the Jump element might be extended for (fourth semantic variant).

[reks99]

Hi,

Try and catch (and final) have been introduced in programming by c++. So at least it is a feature of objectoriented languages. Than the next implementation whishes are for objects, derivation ... I think is implemented in UML-tools. NSD is from the time where procedural programming was state of the art. I use NSDs to clearify the structure of methods.

That is not a critism - I find your proposal very nice.

Just my 2 ct. Rolf

[codemanyak]

Just some preview...

[codemanyak]

Prototype is nearly ready. Generation of Try elements on Pascal import still to be done.

[codemanyak]

Bob (@fesch ) suggested some really good ideas for the further accomplishment: The text of the TRY element could be organized in a similar way as in CASE elements:

• First line = exception variable (name or pseudo declaration)
• Next lines = classifying patterns, parts of the exception string could be matched against (or in future possibly type names as well)
• An optional last line "%" to suppress the finally section.

If the text contains only one line (or one line plus the "%" line) then the catch section will be an ordinary sequence (Subqueue) like it is now (i.e. since version 3.29-07/08. Otherwise the catch section would automatically look like a case structure. This would not BE a CASE element, however, i.e. it will not be removable or editable, nor can elements be inserted before or after it. The branches will be usual sequences (blocks, Subqueue objects), though, like in a true CASE element. The exception classification mechanisms should be different from the CASE selection (which only checks for equality): We need pattern matching in strings and we need type name comparison, and possibly more. Complementarily, Executor methods should not return mere error messages anymore but specific exception objects holding the message (both translated according to the locale and untranslated), a type name if the originating throw instruction from imported code seems to refer to them (patterns like "new xxxxx(...)" or "xxxxx.Create(...)" thus allowing to import catch clauses in a way that has chances to work), a copy of the call stack, and possibly more - open for further enhancements. We should try to keep these future enhancements backward-compatible.

I put them into a new issue.