On Error Block not triggering and catching error, resulting in flow failing

[BLawless]

Hey guys, y'all were pretty helpful with a deeper concept I was trying to wrap my head around, so it's time for a softball (because I'm pretty sure the issue is located between the keyboard and the computer chair).

I've been trying to implement "On Block Error" blocks that will catch any errors thrown by the actions they are encapsulating and handle them so the main flow doesn't fail. Every attempt at this however has failed to catch any errors thrown by the actions the block encapsulates, this is both when I just have actions as well as when I have calls to sub flows that are contained within an "On block error" action. 

To help visualize my issue (see pictures below) I created a very basic "example" flow that creates an array of a certain length and, inside of an "On block error" action, it will attempt to assign a a value to an index that is out of bounds for the array (and should therefore throw an IndexOutOfBoundsException upon attempting that action).

I have not set individual error handling actions (namely because "Set varaible" does not have any "on error" properties), but this is applicable to actions that also have individual error handling properties. Every time the flow attempts the action it will cause the whole flow to fail with a runtime error of the index being invalid. The "On Block Error" is not set to throw an error in response to catching one, so the error causing the flow to fail (from my observations) is the one thrown by the action inside of the "On block error" block. It is worth noting that I in the example I am calling this sub-flow from the Main flow, which has the sub-flow call encapsulated in another "On block error" action, which means two different "On block error" actions have failed to catch and handle this error.

I have tried setting it to "Continue flow run" and either "go to the end of block", "run sub-flow", "go to beginning of block", etc. None of these actions take place, it simply behaves as if it didn't catch the error and the error made its way unhandled to the main flow runtime level and caused the flow to fail. 

I'm hoping this is just a simple configuration issue but if there are limitations to the "On block error" action that I am not aware of then I will happily expand on other scenarios where I am implementing this action (because none of my attempts with "On block error" have been successful thus far). 
Error thrown from the previous run at the bottom reports that the flow was stopped because of the action performed"On Error Block" configuration

[Henrik_M]

Power Automate Desktop cannot handle IndexOutOfBounds exceptions 👎

If you are not 100% sure that the index will be valid during execution, you will have to do a manual check (using %List.Count%) instead of relying on the block error...

[BLawless]

If the "On Block Error" doesn't catch errors like IndexOutOfBounds Exceptions then what errors are they capable of catching? Is there a reference list somewhere? 

I do agree with you that there are means to verify whether or not something should cause an error before performing the action (and make the actions performance conditional to that verification), but with complex flows there's a lot of edge cases that would be better off handled by a simple "On Block Error" segment. In my experience, individually checking all these cases for an error triggers would severely impact the readability and debug performance of the flow. 

[yoko2020 · Accepted solution]

@BLawless 

I agree with your statement, applying individual exception in every action is ridiculous approach if we have complex flow.

But this is the reality, there are some action/error which did not get captured by On Block error. It still does not work as we expected same as like we apply Try Catch Exception in C#/Vb.Net.

[BLawless]

---

@yoko2020 wrote:

But this is the reality, there are some action/error which did not get captured by On Block error. It still does not work as we expected same as like we apply Try Catch Exception in C#/Vb.Net.

---

Marking this as the solution since it touches directly on the general issue, which is that the "On Block Error" doesn't capture every exception the same way a Try-Catch block does in other contexts.

From what I've gathered here it seems that the only errors that the "On Block Error" catches are those listed under the "advanced" segment of the actions "on error" actions. If this is true then actions such as assigning variables are capable of throwing errors that the "On Block Error" cannot handle. This is unverified but makes the most sense based on the discussion here and my observations. 

[yoko2020]

Here is just sample, and there are many more i can not remember.

This error did not catch by the On Block error.

That means if you have internal subflow function for handling global exception, it will not be executed.

(EX: if %GeneralException% = 1 then take a screenshot of desktop and send it via email )

Spoiler

[Rkv_ · Accepted solution]

Hello Everyone, 

The Onblock error can only able to capture the failures happened with the actions which contain on error property and the errors listed with in the advanced tab of the on error.

For example the below action Get window contains On error.

    

So the Onblock error able to capture if this action failed to get window.

The below action is the IF condition, which don't have on error, and this cannot be captured in Onblock error.

[BLawless]

---

@Rkv_ wrote:

Hello Everyone, 

The Onblock error can only able to capture the failures happened with the actions which contain on error property and the errors listed with in the advanced tab of the on error.

---

Thank you @Rkv_  for confirming my theory posted in my last comment (here). Going to update the post to represent your comment as the solution as it points out the core issue. 

The previously marked solution by @yoko2020 is still input valuable as it touches on the core of how PAD under the hood isn't a programming/scripting language but features script-like operations to allow non-programmers to use the automation without having to learn a full programming language and has some limitations as a result (which we may be able to mitigate, see followup further down). 

@yoko2020 wrote:

But this is the reality, there are some action/error which did not get captured by On Block error. It still does not work as we expected same as like we apply Try Catch Exception in C#/Vb.Net.

---

Furthermore thank you for your example contribution (found here). 

As a followup:

I think there is a workaround but it may take some time to verify.

It might be possible (in cases where doing checks for validation on all edge cases is impossible with other actions) to perform the analog equivalent of the PAD action inside of a "Run JavaScript" action and use a try-catch block there (the one under "System", not "Run JavaScript on webpage unless you're using a browser to perform actions on a page). Knowing how variables work between the translation layer of a "Run JavaScript" action and the variable assignment in the flow, this will not work for every scenario, but I think a combination of this and using validation checks using other actions in PAD will cover most (if not all) of advanced edge cases. 

If JavaScript isn't your thing, "Run Python script", "Run VBScript", "Run PowerShell script", and any other "Run [Insert Programming Language here] Script" that Microsoft implements into PAD in the future (C#?) are good alternatives. 

I know for non-programmers this may not be ideal, but if you're running into scenarios where you need the full function of a try-catch block, chances are you're at the level to learn enough about one of these languages to do a try-catch block and scripting analog of whatever action you're wanting to perform in PAD. 

[Anonymous]

💩This is pain in butt. Try-Catch construction that cannot be trusted is a nightmare. It makes it really difficult to explain to customers why the robot terminated without sending any email warning as it should by the process design...  💩