remark
自身のblogにも同じ内容をポストしています。
アクティビティの意味
- 下記のいずれかを満たす間、内部に含めたアクティビティ群を所定の回数実行する
- a)
Conditionに設定したアクティビティがFalseである - b) 内部に含めたアクティビティ群が例外をスローする
- a)
ポイント
b)のほうが事例としては多いかもしれない。ただこれには罠があって、スローされた例外に対する処理が（このままでは）記述できない。したがって自ら設定した回数の例外が発生するまでは、その例外が何であるかはおろか、そもそも例外が発生したのかを（ログとして）把握できないのである。地味だけど、ビジネスユースとしてはちょっと厳しい。
じゃあどうやって実装するのか
二重Try-Catch構造で行きます。重ね方は下記の通り
-
Try-Catch(リトライ全体も失敗したときの処理）-
Retry Scope(リトライ自体の処理)-
Try-Catch(実行/リトライ1回が失敗したときの処理)
-
-
UiPathだと正直可読性がガクンと落ちるんだけど、こうせざるを得ない。
2回目のTry-Catchでは、キャッチ処理に対して必ずRethrowを入れて上げる必要がある。入れないとどうなるかというと、Retry Scopeが例外を直接キャッチしないので、Retry Scope的には成功とみなされ、リトライが実行されなくなる。
1回目のTry-Catchは、Retry Scopeが所定の回数リトライをしても例外をキャッチしてしまう（＝リトライが所定の回数以上失敗している）場合の処理を行う。
デモ
暇ができたら作ります。