【UiPath】呼び出し先がエラーになったら呼び出し元の変数（引数）には値が反映されるか

方向をOut（InOut）にした引数について、呼び出し先でエラーになった場合、呼び出し元には反映されるかを検証した。

結論としては、引数の型がシリアライザブルな型で、TryCatchでキャッチした場合は反映されない。

UiPath（vb.net）ではシリアライザブルな型はInt32、Boolean、String、DateTimeなどが該当し、シリアライザブルではない型はDataTable、Dictionaryなどが該当する。ちなみに、シリアライザブルではない型は引数の方向がInでも呼び出し元の変数が変更されるという仕様もある。

以下にパターンごとに検証した結果を記載する。

1.シリアライザブルな型

まず、シリアライザブルな型としてString型で検証する。
呼び出し元で変数にAを代入、呼び出し先では渡された変数の末尾にB、Cと追記するワークフローを作成し、呼び出し前後で変数の中身を確認する。

1-1.呼び出し先が正常する場合

呼び出し先が正常終了した場合の結果がこちら。
呼び出し前はA、呼び出し後はABCと、想定通りに動作している。

1-2.呼び出し先でエラーになり、「エラー発生時に実行を継続」した場合

呼び出し先のコードのBの代入とCの代入の間にスローを配置し、エラーを発生させる。

呼び出し元のコードでは、「ワークフローを呼び出し」アクティビティのプロパティで「エラー発生時に実行を継続」にTrueとし、エラーを無視させる。

実行結果がこちら。
Bの代入だけ反映され、呼び出し後はABになっている。

1-3.呼び出し先でエラーになり、TryCatchでCatchした場合

呼び出し先のコードにスローを配置するのは先ほどと同じ。
今度は呼び出し元のコードで「ワークフローを呼び出し」アクティビティをTryCatchで囲み、「エラー発生時に実行を継続」のプロパティはFalseに戻しておく。

実行結果がこちら。
Bの代入は実行されているはずだが、呼び出し元には反映されず、変数は呼び出し前後で変わらずAのまま。

2.シリアライザブルではない型

次に、シリアライザブルではない型としてDataTable型で検証する。
呼び出し元で1行のテーブルを構築し、呼び出し先では渡されたテーブルに1行追加を2回行うワークフローを作成し、呼び出し前後でテーブルの行数を確認する。

2-1.呼び出し先が正常する場合

呼び出し先が正常終了した場合の結果がこちら。
呼び出し前は1行、呼び出し後は2行追加され3行と、想定通りに動作している。

2-2.呼び出し先でエラーになり、「エラー発生時に実行を継続」した場合

呼び出し先のコードの1行追加と1行追加の間にスローを配置し、エラーを発生させる。

1-2の検証と同様に「エラー発生時に実行を継続」をTrueに設定。

実行結果がこちら。
1行追加が1度だけ実行され、呼び出し後は2行になっている。

2-3.呼び出し先でエラーになり、TryCatchでCatchした場合

1-3の検証と同様にTryCatchで囲む。

実行結果がこちら。
2-2の検証と同様に2行になっている。

まとめ

呼び出し先がエラーになった場合、引数の型がシリアライザブルな型で、かつTryCatchでキャッチした場合、呼び出し元の変数には反映されない。

	シリアライザブルな型	シリアライザブルではない型
エラー発生時に実行を継続	反映される	反映される
TryCatch	反映されない	反映される

参考