How do you implement a try/catch in Appian RPA no code environment?

There is no direct implementation of a try/catch in Appian RPA, just like there is not in Appian expressions.

But, what problem do you try to solve?

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.html

https://community.appian.com/success/w/guide/3289/appian-rpa-design-development-best-practices

 Stefan Helzle - use the "try" to find the error and based on the type of the error to do something in the "catch" section. Similar to what modern RPAs (UIPath RPA/Blue Prism RPA/Automation Anywhere RPA) are able to implement. 

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.

Think of Appian RPA as a bandaid to integrate a legacy system. Use standard Appian processes for the more complex logic.

Stefan Helzle - you are so right!!! The question is why there is no progress on this bandaid from Appian? any Appian employees here?

 Agentic AI RPA 

Thanks for raising this. You're right that try/catch is common practice in RPA tools. We hear you and understand the desire for robust error handling in RPA, and we're actively working to enhance this area.

While Appian RPA is designed to integrate legacy systems into the broader Appian platform (where you can leverage process models for complex logic and error handling), we recognize that native try/catch capabilities in RPA would make certain workflows more efficient.

This capability is on our roadmap, and we're evaluating the best approach to deliver it in a way that fits naturally with Appian's unified platform. We appreciate this kind of direct feedback, as it helps us prioritize what matters most to our customers.

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.