繰り返し処理の途中からリトライしたい

Legacy32さん
リトライループとはどういったものでしょうか。初心者なもので…

@kana612
繰り返し(後判定)
でいいと思います。
上の例で言えば、条件を Bool変数判定(b処理完了=Falseとか)にするか、i<10(Forループもどき)とかにします。
後者の場合、使用変数が1つで済むので私としては好みです。ループ抜けた後、判定で i<99ならロボット停止と書けますし。

1 Like

質問にエラーで次の商品とあるので停止はしなくていいですね。
しかし、スキップした場合は何らかの方法でわかるようにしたほうがいいと思います。
また、10や 99のマジックナンバーは変数に定数として書いてもいいし、コメントで書いても後でわかればかまいません。
(コーディング基準があればそれに合わせてください)

KatoRさん
トライキャッチではエラーになった場合繰り返しを抜けてしまうと思っていました。
仰る通りできれば理想ですが、トライキャッチアクティビティは、CatchかFinallyのどちらかには処理を設定する必要があるようです…

TryCatchの詳細は以下などを参照していただくとして、

Try
 処理A
 処理B
 ・・・
 i=99
Catch
 Exception(←これは指定が必要)
  処理なしでも可

(今回の場合、Finallyは何も書かなくていいでしょう)

上記の場合、処理A~i=99までの間のどこかでエラーが発生したら、即時Catch Exceptionへ処理が移ります。で、Exception内の処理を終えたら、Tryブロックを抜けるだけです。エラーでループを抜ける場合はここに breakなどを記述しないと抜けてくれません。
(i のカウントアップはTryブロックの外に書くほうがいいと思います)

ちなみに Finallyは例えば Tryの中でファイルオープン、クローズする場合、エラーでクローズ処理に到達できない時のためなどに、Finallyにクローズを書きます。(Finallyはエラーの有無に関わらず実行される)

1 Like

@KatoR さん
CatchesにException設定抜けていただけでした。試してみます。ありがとうございます。

1 Like

Exceptionについては様々な種類がありますが、全てのエラーを無視したいのであれば、
System.Exceptionを指定しておけば大丈夫です。
ただし、全てのエラーを処理してしまうため、想定外のエラーにも気づけない可能性もあります。そのため、起こりうるエラーが分かっているのであれば、特定のExceptionのみを指定し、その他想定外のエラーについては発生時にExceptionを追加する方がフローとしての品質はより良いものができると思います。

以下は参考までに。
エラーの種類によって動作を分類したいのであれば、Exceptionに複数の種類を設定し、
それぞれに対してフローを作成すると良いです。
例えば、ECサイトから商品名が取得できず、Nullになることがあった場合、Null参照のエラーなどが考えられます。
この場合、NullReferenceExceptionを設定すれば、商品名が取得できなかったときの処理ができます。

1 Like

ご丁寧な説明ありがとうございます。
今回の件からは少し逸れますが、System.Exceptionを設定しているのに例外発生時Catchesに入ってくれない原因って何か考えられることありますでしょうか…?

System.Exception発生時の処理に何も無ければ、例外発生したかは見た目では分かりません。
System.Exceptionに入ったか確認したい場合は、添付した画像のようにメッセージボックスアクティビティを使用しメッセージボックスとして出力するか、メッセージをログアクティビティを使用して出力タブにメッセージを出力する方法があります。
前者の方法の場合、メッセージボックスが表示されるため、シナリオが停止しますのでご注意ください。

フロー

出力タブ(左下)
Try-Catch2

1 Like

メッセージボックス入れてますが表示されません。
エラーが発生していること、Catchesに入っていないことはデバッグ実行により確認済です。

エラー発生時のスクリーンショットを投稿いただけますか?
可能であれば、Try-Catchアクティビティもお願いいたします。

こんにちは

可能性のひとつとして
Global Exception Handlerが設定されていて、ErrorAction.Ignoreが設定されている
ということはありませんでしょうか?
プロジェクトパネルで左まわりの矢印みたいなアイコンのファイルがあると怪しいかも。

2 Likes

@Yoichi さん
グローバルハンドラーにErrorAction.Abort設定しています。
トライキャッチよりもグローバルハンドラーが優先されるということでしょうか。

こんにちは

当該xamlファイル内でtry-catchしていない場合は、そのxamlを抜ける際にGlobal Handlerに遷移すると思います。ただAbortならそのまま外のtry-catchで捕捉されるようにも思えますが..。Continueならrethrowされるので、そとのtry-catchで捕捉されると思います。
このあたりの挙動の確認をした方が良いかもしれません。

Debugモードで実行すると、例外発生時に停止状態になると思うので、そこからステップ実行(F11)で動作を追われると、実行の順序が分かると思いますが、ご確認できますでしょうか?

1 Like

@Yoichi さん

トライキャッチしているxamlファイル内でエラーが発生しています。(ワークフローの呼び出しはしていません。)
デバッグ実行時、エラー発生→グローバルハンドラー の流れで、Catchesには遷移しません。
@KatoR さんにもコメント頂きましたが、社外秘情報のためスクリーンショットやアクティビティを掲載することはできません。申し訳ありません。

@Yoichi さん
やはり、グローバルハンドラーを削除したところトライキャッチに遷移するようになりました…
トライキャッチ使用時にはグローバルハンドラーは設定できないのでしょうか…
(実際はグローバルハンドラーも設定したいのです。)

こんにちは

再現できました。

try-catchで捕捉される前にGHに捕捉され、そのGH内でAbortしているため、そこで実行が停止しているものと思われます。
GH内での動作をAbortではなくContinueとすると、その後try-catchで捕捉できると思います。
(実際はこのあたりの動作を細かく指定してあげる必要があると思いますが)

@Yoichi さん
ありがとうございます!!
参考にさせていただきます。

1 Like

@Yoichi さん
@kana612 さん

グローバルハンドラについて仕様を確認しましたが、Abortの場合、グローバルハンドラを抜けたあと、元のフローの処理は停止するようです。
解決していると思いますが、私自身の備忘録として残させていただきます。

あまりお力になれませんでしたが、これからもよろしくお願いします。

2 Likes

@KatoR さん
情報ご提供いただきありがとうございます。
今回はContinueにして処理を進めます。