例外処理

完了

例外は、事実上すべてのアクションで発生する可能性があります。 このため、ほとんどのアクションのプロパティには、エラー発生時ボタンがあります。 このボタンをクリックすると、アクションの例外処理設定にアクセスできます。

アクション レベルの例外処理

最初の例では、クライアントのデータベースをアクセスできないため、データベースと通信するアクションによって例外が発生しています。

これを回避するには、アクションのプロパティを開き、エラー発生時ボタンを押します。

このビューでは、既定のルールを有効化するか、または新しいルールを追加することにより、アクションの例外処理を構成できます。 これらのルールは、この特定のアクションが失敗した場合と、並べ替え後の順序に従って有効になります。

ユーザーが作成したルールをドラッグ アンド ドロップして、ルールを並べ替えることができます。

上の例では、このアクションが失敗した場合、2 秒後に 1 度再試行され、その後、データベースのステータスを管理者に通知するためにメールを送信するサブフローが実行されます。 また、アクションによって、データベースがダウンした状態であることを示す変数の値が変更されます。

既定では、このアクションの実行中に例外が発生した場合は、例外処理が有効になりますが、例外処理が特定の例外タイプでしか発生しないように構成することもできます。 各アクションには、生成される可能性がある特定の例外タイプがあります。

[SQL 接続を開く] アクションのプロパティの 選択済み例外がある [入力済み例外処理] タブ。

この例では、例外処理ルールは、データソースに接続不可の例外が発生した時のみに適用されます。

ブロック レベルの例外処理

場合によっては、失敗の可能性があるアクションを特定できないことがあります。また、すべてのアクションに同じ例外処理ルールを適用することは実用的ではありません。

たとえば、Power Automate デスクトップが Web ポータルと対話するフローについて考えてみます。 このタスクの実行中にポータルまたはブラウザーが応答しなくなった場合は、ブラウザーを閉じ、もう一度起動して、Web ポータルの対話全体を最初から再起動することをお勧めします。 ただし、Web ポータル インタラクションは数十、または数百のアクションに及ぶことができます。したがって、各アクションに同じ例外処理ルールを個別に割り当てることは現実的ではありません。

ブロック エラー発生時 アクションでは、1 つの例外処理ルール一式をアクションのブロック全体に適用できます。

ブロック エラー発生時 および 終了 アクション間のアクションは、ブロックの例外処理のルールによって影響を受けます。

この例では、ブロック内のいずれかのアクションに失敗すると、ブロックのルールが有効になります。Web ブラウザーを閉じるサブフローが実行され、ブロック全体が繰り返されることで、応答しない Web ページまたはブラウザーによってフローがクラッシュすることを防ぎます。

例外処理の優先順位

例外処理は下位から上位の順番に適用されます。つまり、アクションが失敗した場合は、その個別の例外処理ルールが直ちに有効となります。 フローを再開ためにそれだけでは不十分な場合、ブロック レベルの例外処理が有効となります。

したがって、アクション レベルの例外処理ルールは、それぞれのブロック レベルのルールよりも前に実行されます。