I confimed today while investigating a customer report that all versions of ETO/Intent through 2015 contain a flaw when Try/Catch statements are nested. Nesting means including one Try inside a currently-open Try. It does not apply when the code within a Try clause evaluates another rule that contains a Try clause. While it certainly does not fail all the time, operations after the inner Try has ended normally (does not have an exception occur inside it) and is then followed by an exception can see a corrupt data stack. This can lead to any number of possible issues, depending on what the data stack contains.
I strongly recommend that all nested Try statements be re-written to not be nested; this is usually pretty simple, but if you need recommendations, please ask. It will be one of the first things I will look for when otherwise-unexplained anomalies occur in Try/Catch code.
The problem will be fixed in a future release, so nested Try statements are legal Intent Language syntax and will not be restricted.
This is a simple test case that demonstrates the problem:
Rule DE1085_fail As Any Dim s1 As String = "foo" Try s1 = s1 + "bar" Try s1 = s1 + "baz" Catch Error s1 = "inner catch" End Try s1 = s1 + Error("me") Catch Error s1 = "outer catch" End Try s1 = s1 + " end" Return s1 End Rule
You can paste this into the dynamic rule window of MinHost, and you will get an internal stack error when it is evaluated. The workaround is to remove the inner try/catch. The cleanest way to do that is to put it in a different rule. Even though that will still have one try "within" another, it won't trigger the problem, because they aren't in the same rule body.