グローバルハンドラー.xamlのRetry変数とリトライ回数について

日本 フォーラム
1

こんにちは
UiPath Studio 2025.0.161 community editionのユーザです。

下記の仕様の、他人が作成したグローバル例外ハンドラーのサンプルコードを実行してみました。

仕様：InputDialogで「ビジネス例外」と「アプリケーション例外」の選択メニューが表示され、
前者を選択すると、Main.xamlにて「ビジネス例外」をThrowし、グローバルハンドラー.xamlにて「ビジネス例外」に対応した処理が、後者を選択すると、Main.xamlにて「アプリケーション例外」
が発生し、グローバルハンドラー.xamlにて「アプリケーション例外」に対応した処理が実行される。

3点ご教示ください。

1.グローバルハンドラー.xamlにRetryというint32型変数があり、初期値は0です。

グローバルハンドラー.xamlに

errorInfo.RetryCount < 3

という構文があることから、リトライ回数をこれで決めているのかと思いましたが、
変数Retryの初期値を,0から5に変えてみましたが、リトライ回数は4回と変わりませんでした。
Retryは何をしているのでしょうか？

2.errorInfo.RetryCount < 3の構文で実行されるリトライ回数は4回と決まっているのでしょうか？ログを見るとそう見えます。

The image contains a log file with both information and error messages, including system exceptions and termination activities, written in Japanese. (Captioned by AI)
The image contains a log file with both information and error messages, including system exceptions and termination activities, written in Japanese. (Captioned by AI)1044×261 5.61 KB

3.ビジネス例外を発生させたところ、ログを見ると4回ErrorHandler.xamlを呼び出していますが、グローバルハンドラー.xamlのアルゴリズムでは、1回ErrorHandler.xamlを呼んでワークフロー終了するはずです。分かりにくいですが、グローバルハンドラーではビジネス例外も、アプリケーション例外も4回エラー処理を繰り返す仕様なのでしょうか。

This image displays a log file with multiple entries in Japanese, indicating the start and end of processes and various errors encountered. (Captioned by AI)
This image displays a log file with multiple entries in Japanese, indicating the start and end of processes and various errors encountered. (Captioned by AI)968×427 6.21 KB

プロジェクトをUpします。
グローバル例外ハンドラサンプル2.zip (240.4 KB)

2

@gorby

For your first question,

Check for which variable you are changing the value,
in expression there Retry Count if you changed to Retry variable it wont effect

For your second question there is no any fixed retried but ideally it will be better to follow three times. based on your requirement

Happy Automation!!

3

Does the syntax errorInfo.RetryCount < 3 determine the number of retry attempts as 4? Looking at the logs, it seems that way.

4

上記で共有されているプロジェクトファイルは、以下のトピックで共有されていたものと同じようなので、上記の実行結果とは異なるプロジェクトではないでしょうか？

5

失礼しました。添付プロジェクトを下記に差し替えました。ご確認下さい。

グローバル例外ハンドラサンプル2.zip

6

I can’t read your workflow due to language,

but make sure one thing where that condition is placed and make a note execution retry will start with 0,1,2,3 total is 4 retries

7

うまくアップできていないようです。ご確認お願いします。

8

最初の投稿にUpしましたが、こちらにも同じプロジェクトをUpします。
グローバル例外ハンドラサンプル2.zip (240.4 KB)

9

この認識が誤っています。
resultがErrorAction.Continueなので、GlobalHandlerを抜けると再び例外がスローされます。
これが各シーケンスを抜けるたびに繰り返えされるため、複数回GlobalHandlerが呼び出されることになります。

10

変数定義以外でどこにも使用されていないので、何ら影響しないと思います。

2.errorInfo.RetryCount < 3の構文で実行されるリトライ回数は4回と決まっているのでしょうか？ログを見るとそう見えます。

リトライとしては３回かと思います。→そのため４回例外が発生しています。
リテラルの3がハードコーディングされていますので、ReteryCountが3になったときにErrorHandling_Terminateに流れると思われます。

11

明示的にresult=ErrorAction.Continueなどと書いていないので、どうしてそうなるか分かりませんが、それではどう書けば、ビジネス例外処理を1回で済ますことができますか？

12

分からないのは、
errorInfo.RetryCount < 3
は条件分岐のElse側に記載しているのに、Then側に記載したビジネス例外にもその影響が及んでいることです。ビジネス例外のエラー処理が1回で済むような記載は可能でしょうか？

13

Yes, you can segregate them based on exception type,

for that you need to one thing, you need store the exception into two variables.
If it is System exception store it in systemExceptionVariable, if it is Business exception then use another variable was BusinessexceptionVariable, here check business exception variable is nulll if it not null go to Business exception flow,
same like System exception as well

Please mark solution if you find the solution.
Happy Automation!!

14

どこからこのコードを持ってきたかは存じませんが、デフォルト値に頼るかつコメントもない書き方が不親切なのだと思います。

それではどう書けば、ビジネス例外処理を1回で済ますことができますか？

例えば、公式ドキュメントにある通り、ErrorAction.Abortになるかと思います。

分からないのは、
errorInfo.RetryCount < 3
は条件分岐のElse側に記載しているのに、Then側に記載したビジネス例外にもその影響が及んでいることです。ビジネス例外のエラー処理が1回で済むような記載は可能でしょうか？

及んでいません。Step-Inやアクティビティログを機能を使えば、どのルートを通ているかは把握できますので、それを行った方が良いかと思います。
前述しましたが、ビジネス例外時に複数回GlobalHandlerが実行される理由は、ErrorAction.Continueによる再スローであり、errorInfo.RetryCountとは無関係です。