One of the pain points with Logic Apps is when you want to throw an error. I often find that as the logic within the workflow gets complex I end up with a lot of condition shapes to handle different exception scenarios and I end up with a massive nested workflow.

There is the option of using a terminate shape but this has the limitation that your workflow will stop executing at this point. In my case I will often be executing a try/catch scenario and I want to throw an error which will make the execution jump to my catch block so I can log the problem and safely exit. If I do this I can take a log of shapes out from my workflow.

If we take a look at the below very simplified example we can see that when we use the terminate shape in a try catch pattern then the catch never executes.

What we decided to do was to implement a helper Logic App which simply throws errors. If we now take a look at the try catch pattern you can see the throw exception makes the execution jump to the catch block.

The net result of using this in a more complicated workflow is that when you do a condition test which fails and you want to exit, you no longer need to do a load of error handling in every condition and then terminate you can just throw an exception and jump straight to your catch block. This can make your workflow a lot simpler and get rid of the need for a lot of nested conditions simply handling the logging and safely exiting on every error scenario.

What does the throw error Logic App look like?

We created a simple workflow which accepts a message from the logic app which wants to throw an error. We then return a response with a 500 error code. We can also add some logging if we wanted.

In the caller logic app which wants to throw an error we simply pass in which logic app is throwing the error and the error message.

Do I have any other options to implement my throw error shape?

Absolutely, it depends what you prefer. We chose a child logic app call because its easy but you could also easily implement something with either an Azure Function or an operation in APIM.

Basically you want something which will throw an error.

The other reason we chose a Logic App was that it would allow us to implement any logging later in a single place and we could easily see all of the thrown exceptions in 1 place.

Are there any gotchas to watch for?

Yes the one thing you want to watch for is when you call your helper logic app which will throw an error then you want to turn the retry policy to none. This will ensure that the caller logic app doesnt just keep retrying as per the default policy.


Buy Me A Coffee