8
4

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?

【UiPath】実用的な例外処理を考えてみた

Last updated at Posted at 2023-11-24

1.はじめに

 個人的に実用的な例外処理は何かを考えてみました。その結果以下のようなポイントが挙げられると思います。
 <ポイント>
  ①例外が発生したことが瞬時にわかる
  ②例外が発生したプロセスがわかる
  ③例外が発生した場所がわかる
  ④例外が発生した内容がわかる
  ⑤(例外が発生した時間がわかる)
  ※即時メールを送るという側面から一旦細かい時間という部分は優先度を落として考える

2.課題

 上記には挙げていませんが、例外が発生した場所以外に発生したデータを知りたい場面が良くあります。データを把握しないと、リカバリポイントが明確にならないということで、以下のいずれかの方法をとっている方が多いかなと思っています。
 ・処理対象データの情報をログ出力している
 ・処理対象データをExcelなどに保存・マーキングしている

 これらの方法をとることは非常に重要ですが、ログを見に行ったり、保存データをみたりする必要があります。また、ログ出力する場合は処理対象データ量が膨大になると、データベースの容量を増大させたり、端末のログを増大させ、スローダウンやアプリケーション停止などを招くことがあります。

3.対応方法(提言)

 対応方法の1つとして、TryCatchを適切に設定するというのが挙げられます。Main.xamlにしかTryCatchがないという方もいらっしゃるかもしれませんが、以下のような構成イメージにすることでどのxamlで発生した個別のメッセージを設定することで判断しやすくすることができます。
 image.png

 個別のメール用例外メッセージを設定する方法としては、Dataプロパティを利用します。これはSystem.Exceptionクラスにあるプロパティであり、例外発生時専用のものとなります。この内容をメール本文に載せ、例外の大まかな発生個所を人が視認しやすいメッセージにすることが可能となります。

 さらに、これを応用して、繰り返し処理に適用をしていきます。イメージ図としては以下のようになります。
 image.png
 このように繰り返し処理にも個別にTryCatchを付与します。ここでポイントになるのは繰り返し処理の現在のインデックスを変数として出力し、同値をメール用例外メッセージに設定することで無駄なログを出力せず、どのデータを処理していたかを明確にすることができます。
 実際のxamlファイルの例は以下となります。
 image.png

4.最後に

 これらを応用していくと、以下のようなメール通知を受け取ることが可能になります。
 image.png

 Main.xamlの例外処理部分の実装は以下の通りとなります。
 image.png

 本記事はあくまでも個人の見解を述べているものとなりますので、参考情報として頂ければと存じます。

8
4
0

Register as a new user and use Qiita more conveniently

  1. You get articles that match your needs
  2. You can efficiently read back useful information
  3. You can use dark theme
What you can do with signing up
8
4

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?