In order to optimize our programming an equivalent to the VBA ‘go to’ would be immensely desirable. This way I can create if-statements during my sequential code and if certain conditions are met then jump to other parts of my code.
Adding GoTo’s would be very difficult (if even possible) in my opinion, due to:
there are no static line numbers in XAML’s. If you’ll check them in any text editor, f.e., adding a new reference would change all line numbers, meaning that a line-dependent GoTo would land in a middle of an activity which could go very wrong
there are no static labels to jump to (these could be added in theory, but that’s another thing) - activity names are not unique, and the ID that’s added to the XAML is just class name + sequential number. If you copy the exact same IF statement, paste it below and delete the old one, it will have a different ID
there are certain scope limitations for a GoTo that the Studio will struggle to check (f.e. you can’t jump to a Try statement from outside) since the XAML’s are not compiled so their state is not known until they’re read by the interpreter (AFAIK). Also certain activities create additional threads (parallel, parallel foreach, pick branch) which could add to the complexity of validation that the workflow will even run
longer workflows are hard to read as-is, adding GoTo’s to the mix will convolute it further and introduces risks that the state of the robot in a certain part cannot be known - testing and debugging gets even harder
refactoring (extracting workflows for reuse) and changes can be made more difficult due to uncertainty of current state at any point
Assuming that above are correct, jumping with GoTo would only be safe (or safe’ish/possible) in the same scope/stack depth - and flowchart does that already while being visually much more readable.
Don’t get me wrong, I’m not bashing on the idea and GoTo has its uses in complex nesting (or in C in general, or as a semi-exception handler in some situations) - I just don’t see a use for it in WF-based solution.
And not that my opinion matters, as it’s up to UiPath anyway
Marc this is a very, very hard to implement feature and I can’t see the gains out of it. Like Andrzej said, in terms of project organization it will create a lot of troubles. Why not split your automation in smaller pieces and use Invoke Workflow, instead of Go To? This is similar with a newer and better programming paradigm (use functions instead of jumping to instruction lines)
From what I’ve seen so far, there is actually a Go To equivalent. Instead of a command, you could use the flowchart and simply connect the activity to an upper or lower section…
So if in the middle of the process you want to jump to the end, just connect the activity with the last and you will jump straight to finish
In UiPath there should be activities like “Jump to Label/Step/Activity” using which we can directly jump to a specified location.
We should also be able to place this activity in catch block, so even if in case of any exception we can resume the workflow from any perticular stage.
This can be achieved using booleans or strings and flow decisions / Flow Switch.
Assign a boolean to true if you want it to route or assign a string to ‘Go To Label 3’ or ‘Go To Label 4’ if you have multi routes?
Agree in such cases, but in case of exceptions, how can we jump out of the catch block and resume the process ?
Hi, You can use Invoke Workflow Activity.
It wouldn’t be hard at all. All that’s needed is a corresponding “go to here” Activity that allows you to designate where the “goto” should jump to. Simple.
All the other issues you mention would be up to the developer to manage.