Some really good ideas for the further accomplishment of TRY elements.

[codemanyak]

Bob (@fesch ) suggested some really good ideas for the further accomplishment of the exception handling elements introduced with versions 3.29-07/-08: 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 (EDIT: obsolete, see first comment).

If the text contains only one line (or one line plus the "%" line) then the catch section will be an ordinary element 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.

Originally posted by @codemanyak in https://github.com/fesch/Structorizer.Desktop/issues/56#issuecomment-476157016

[codemanyak]

Revision of concept: We still need an optional else branch (a possible general catch clause like catch(...) in C++ or catch(Exception e) in Java), so the last line should be reserved for this default branch (including "%" as its suppression), to be compatible with CASE elements. Bob's supposal said to add a "finally" line in the very last position if the finally section is to be shown. To be backward compatible with the current version, I would prefer something to suppress the finally section instead of enabling it, however. Could of course be an arbitrary "strange" string, so it's just an aesthetic question... EDIT: Alternatively (and preferrably), the element editor for TRY elements could be equipped with a checkbox for a finally clause being selected by default.

[codemanyak]

Additional remark (and reminder): The matching of the cases (representing the catch clauses) is to be done sequentially such that the first match "wins" the game. (Technically this is more or less obvious but it should also be spelled conceptionally. Some warning mechanism should be implemented for the case that the user disables a non-empty finally block. It is possible to delete the contents or to preserve them for later reactivation. The latter seems more user-friendly. On the other hand, it might be surprising on reactivation. So, instead of completely hiding a non-empty finally block, it might be indicated in the diagram element, either as a disabled element sequence or just with some symbol or automatic comment line or the like.

[codemanyak]

Well, I reviewed the proposals and came to the following conclusion:

1. In order to distinguish different exception string contents, a change is not necessary because a regular CASE element or an IF-THEN-ELSE-IF chain may be used to do this within te catch block.
2. Hence, a "built-in" CASE-like structure is only justified in order to select upon different data types, which does not make sense regarding Executor by now because it does not provide other "exceptions" than strings. The mechanism might of course be changed in a way that the Executor methods return Objects insted of strings, but on code export or import this will not necessarily be of any help because the respective data types or exception classes would hardly correspond. So it will still need some contemplation.
3. If an implementation of the CASE-like proposal is to be done (cf. 2) then a single line of text shall have the same effect as by now, i.e. work as if there were no CASE-like structure at all.
4. For the finally block, the soundest solution seems indeed to be a checkbox in the InputBox that might be unselected by default such that no finally block is visible. But if there are elements in the finally block then it is to be drawn no matter whether the checkbox is selected or not, unless all content is disabled (in the usual way).