How do you implement a try/catch in Appian RPA no code environment?
Thank you.
Discussion posts and replies are publicly visible
Use conditional blocks (Element exists?, Window exists?, return codes) to branch flow: success path = try, failure path = catch.For task failures, handle in calling process model via Execute Robotic Task's error outputs (status, message).Better to go through this documented links:https://docs.appian.com/suite/help/26.1/rpa-9.17/design-patterns.htmlhttps://community.appian.com/success/w/guide/3289/appian-rpa-design-development-best-practices
Shubham Aware - yup, I was aware of this "go around" techniques. I was hopping for something more powerful, something that modern RPAs (UIPath RPA/Blue Prism RPA/Automation Anywhere RPA) have.
I disagree that a 'catch' block is 'powerful' in the longer term. Most of the time they are a 'code smell' because they imply that a developer has not checked the assumptions about initial conditions / data in their code prior to running it. The reality of nearly all code I've written and reviewed is that a 'catch' block is just a way for developers to ignore problems by logging them to deal with later. Sometimes that is all that can be done (e.g. leaky abstractions, where a lower-level library throws a generic exception with no relevant means of handling it in a specific way), but most other times it is far more performant and maintainable to check assumptions ahead of the try() block.
The lack of generic error-handling in Appian, while absolutely frustrating at times in early development, is a way to force developers to properly address errors in their code as part of productionization. I do wish Appian would formally support try/catch (specifically to gracefully handle issues with data-driven dropdowns), but I also know developers would simply abuse it.
Jesse Knight - sorry but I disagree and this is the reason why: a try/catch combined with a "throw" or a "rethrow" (to force the generation of an error) is a powerful way of directing the code to a specific part of the program that should run or not. That means control not "developer has not checked". By the way, couldn't find in this Appian RPA a "throw" (or a "rethrow") activity but again, the number of things that are missing ... I don't really want to talk about it because is very frustrating.
Sure, re-throwing an Exception is a thing. But again, that simply means you're pushing the problem off onto some other part of the code passively, rather than proactively dealing with it. In some cases, such as generic connection handlers, that makes sense. Yet in most cases it's simply a way to punt on a problem that should be dealt with.
The time / effort to handle an error will be spent at some point, whether it's dealt with immediately via checks or rethrown and dealt with in a few months as a mess of data / processes that need to be cleaned up.
Jesse Knight - so your point is let's not ask Appian to implement any other activities because we don't need it ("pushing the problem off"). And also your point is UIPath RPA / Blue prism RPA / Automation Anywhere RPA ... they are not modern RPAs, top of the market systems ... they are all stupid guys that don't know what they are talking about. Jessy ... really????
That's not my point - see above, where I think there are great use cases for specifics on try/catch. My point is that it was never a great idea in software (even before RPA) to use try/catch as the only approach to error handling.
As for whether RPA as a fundamental technology is even relevant these days.... in my personal opinion, it isn't. But Appian doesn't typically listen to my hot takes when determining what's on their roadmap.