呼び出し先のワークフローでTryCatchアクティビティは必要でしょうか?

UiPath Studioで呼び出し元ワークフローを作成し、ワークフロー呼び出しアクティビティで、呼び出し元ワークフローから3個のワークフロー(xamlファイル)を呼び出しています。(構成は添付画像参照)
呼び出し先のワークフローでは、Excelの読み書きを行います。
呼び出し元ワークフローはTry Catchで囲んでいるので、呼び出し先のワークフローでアプリケーションエラーが発生し、エラー発生をスローした場合、呼び出し元ワークフローのTry CatchでエラーをCatchして、メッセーをログなどのエラー処理を行います。
この前提で2点質問します。
1.この構成だと、呼び出し先のワークフロー処理を再度Try Catchで囲む必要は無いという認識ですが合っていますか?
2.もし、呼び出し先のワークフロー処理を再度Try Catchで囲む必要があれば、それはどのような場合でしょうか?

こんにちは @gorby ,

もう少しわかりやすく説明してもらえますか.

Thanks,
RajKumar

分かりにくくて済みません。
フレームワークという言葉が分かりにくいかもしれないので、やめました。
編集したので、再度質問をご覧ください。
よろしくお願いします。

こんにちは

1、
呼び出し元から出力するエラー内容がワンパターンなら、呼び出し先のトライキャッチは無くても良いと思います。
(例:アプリ〇〇でエラーが発生しましたなど)

2、
エラー発生箇所ごとに、エラーメッセージを分けたい場合に呼び出し先でもトライキャッチを置きます。
大前提として呼び出し元のCatch部には「スイッチ」アクティビティを起きます。
呼び出し先のトライキャッチではCatch部にエラー内容ごとのエラーフラグを代入する処理を起きます。
(例:int_ErrFlag=1 / int_ErrFlag=2、など)

処理が呼び出し元に戻って来た直後に、上記のエラーフラグが立っていればCatch部のスイッチに進み、エラーフラグの数字ごとに異なるエラーメッセージを出力できる、という仕組みです。

回答ありがとうございます。
考えたのですが、ご指摘いただいた事例の他に、呼び出し先に、Excel行順次読み出しなどのループ処理があり、ループ中にエラーが発生しても、処理を止めたくない場合、呼び出し先にTry Catchアクティビティを配置する必要がありそうな気がしますがいかがでしょうか?

そうですね。
ループ中のエラーで処理を止めたくない場合にTryCatchを置くのも適した使い方だと思います。
その場合、私ならCatch部にエラーフラグの他、List型変数にそのExcel行の初列の値などを追加してエラー内容を累積し、処理の最後に正常に読み取れなかった行やその値をログとして出力します。

UiPathのログってシステムが出す大量のログに紛れて見にくいので、私なら、処理を行ったExcelの行にワークフローが出すエラーメッセージを追記します。