Should use try catch For child bots

​@vshuaib Let’s assume your parent task bot does nothing more than Task Bot: Run actions, launching the child task bots.

The only way the parent task bot would receive an error is if the child task bot is missing. If that’s important to you to track, then yes, add Error Handler: Try in the parent task bot.

Generally speaking, the parent task bot will also be handling the returned message(s) from the child bots. Once again, if any of those things could cause errors, then you want to add Error Handling.

Now, we have shifted gears to using Mozart Orchestrator Processes. This is far easier to deal with multiple task bots (and API tasks, forms, etc.), updates (especially in a group setting), and the moving of data. You may wish to start building using that structure rather than the outdated parent/child model.

https://docs.automationanywhere.com/r/cloud-build/mo-introduction

Hi ​@vshuaib 

I recommend using both:

• Keep Try/Catch inside each child bot
• Add one top‑level Try/Catch in the parent bot around the Run actions

Why both?

Think of it as two layers of protection:

1. Child bot Try/Catch

   • Handles errors local to that child (file missing, bad data, etc.)
   • Can log details, take a screenshot, or do cleanup specific to that child

2. Parent bot Try/Catch

   • Wraps the Task Bot → Run actions
   • Catches anything that still fails at the overall workflow level
   • Lets you decide: stop the whole process, log a single summary, send an email, etc.

What it looks like

Child bot pattern:

ChildBot_X
  Try
     (all main actions of this child)
  Catch
     - Handle/log the error for this child
  Finally (optional)
     - Cleanup this child’s resources

Parent bot pattern:

ParentBot
  Try
     Task Bot: Run → ChildBot1
     Task Bot: Run → ChildBot2
     Task Bot: Run → ChildBot3
  Catch
     - Save exception message to a variable
     - Save line number to a variable
     - Log or notify using those details
  Finally (optional)
     - Close shared apps / files (browser, Excel, etc.)

This way:

• Each child is robust on its own.
• The parent still has a single, clean place to react if anything goes wrong anywhere in the flow.

That’s the pattern I now use by default when I break automations into parent/child bots.

See also:

Error handler package

Catch action details