It is ofcourse common to see a set of sequences that assimalate the java like try catch. One thing that is not the same, is the scope in the initial excuting sequence. All values are rolled back to before the sequence was called and so even if you define the field before hand, it will only have its previous value (pipeline rollback).
I have not heard anyone specifically mention the Event Manger. Is it not suitable for separating the certain actions, like logging, that are asynchronous and auxillary to program flow? It almost sounded like sonam was partly speaking of this but maybe you were referring to something more powerful? I use it for logging exceptions through a class of services to a specific location. It saves about 4 lines of code per service.
I would like a retry (with preserve) construct and to have code-watches with triggers (wwt). The wwt is having an action triggered by a particular state in the FLOW being true. Pretty much it is emboding aspects of the publish and subscribe model we use to the FLOW code at the document AND field level with less kludge. You could have a separate pane that you assign a service to run when a certain condition is met.
I feel awry about nested sets of these. That was something that ate at me to do right one time. The region was small enough to not warrant a whole separate flow service, but its error handling was complex enough to not be solvable at the same level. Some values needed to be in place to preserve field mutations before a following step was executed. I did want to know some of the values and allow others to rollback. an example:
map a = 0
– map b = 1
– seq exit-on:success
— seq exit-on:failure
---- map c = dynamicsql3 b
— seq exit-on:failure
---- map d = dynamicsql4 b
— seq exit-on:done
---- map b = -1 ## keep b; rollback c,d
– map ## operate on b, c, d
- seq exit-on:done
– map a = -1 ## keep a; rollback b
map ## operate on a, b
For the most part, I treat transient errors as hiccups, so I use instead a REPEAT step and let it run 3 times with a sane time between. If it really was simply a delayed connection or waiting file state, I would soon have proper access, otherwise I allow the service to error as if I was sure the resource would never be obtainable. That is a wrapper to the normal call and the parent will handle any needed exception situations. It could be a second wrapper with a single seq exit-on:done that did a boolean return. That in fact is how I setup service that I would only do a log in error and continue the rest of the execution. The logging would be dumped off to Event Manager.
If you are going to include the try-structure in a recursive service, try to limit the re-entry point to one location. I just generally also try to not have mutually recursive definitions as that is too magical for me in all but very simple cases. Good day.