【いきなりStudio10】（ソース・テンプレート編）Try-Catchアクティビティでガチろう～トライキャッチこそ、ガチラー（安全にロボットをコカす人）の嗜み。教科書どおりな人は必ずFinallyでやらかす( ´∀｀ )

さてと、連投（これ終わったらジムに行こ💃）
前回、

ロボットを安全にコカすアクティビティ

Throwの考え方と使い方

については説明したので～～～
今回は、

コケた後の対処方法
☞エラーハンドリングの基本

について、説明してく💃
んだば、早速( ´∀｀ )

トライキャッチアクティビティ

ま、知識としては、

アクティビティ - トライ キャッチ

を見といてもらうとして( ´∀｀ )

前回のスローのみでトライキャッチがないとどうなるかを検証( ´∀｀ )

前回までのソースをMainから実行してみる( ´∀｀ )

コイツな

てな感じのエラーダイアログボックスが表示される

出力の詳細を見ると、

まあ、こんな感じな
うじゃっとすっごいことになってんね( ´∀｀ )

今度は前回と同じ位置でブレークポイントを入れて

ココな

Main.xamlから、今度はステップインで実行して、

コイツな

エラー発生後にどういう処理を辿るか

を見てみよう( ´∀｀ )

ホイ、前回と同じところで同じエラー

ステップインで、ブレークポイント箇所の次のアクティビティへ行くか

ん❓👀

通らずにどんどん外側の方に赤いエラーが行ってんね👀💦

ReadConfig.xamlを呼び出してた
RobotMainに行ったねえ( ´∀｀ )

さらにどんどん外側へ～～～( ´∀｀ )

Main.xamlに戻り―の

さらに最後までステップインを続けると最終的に

で、前回同様のビジネスエラーメッセージが
さっきと同じように出てるね( ´∀｀ )

とまあ、実はこれが

ロボットが安全にコケてる

状態なんで、別にこのままで良ければ何もしなくていいんだけど、

エラー発生時に、エラー発生用の処理をしたい

って時に有効なのが、今回の

Try-Catchアクティビティ

操作

アクティビティとしては

コイツな( ´∀｀ )

組み込むと、

こんな感じなんだけど、、、

ここでポイント①：処理単位を意識する

トライキャッチは、

• Try：正常処理（この中でエラーがあれば例外にスロー）

• Catch：例外処理（例外＝スローされたエラーをキャッチ）

• Finally：正常であろうと、例外であろうと必ず最後に処理される

って感じで今まで作っていたのは、

正常処理＝ReadConfigって単位で
ひとつの処理で固まってる

ので、こんなデザインになってると

てな感じでアクティビティ単位で移動しよう
て人がいるんだけど( ´∀｀ )

今まで作っていたシーケンスをまるごと
Try＝正常処理
の中に移動してあげるだけ( ´∀｀ )

縮めるとこんな感じ

で、赤いビックリマークにマウスの矢印を当てると

CatchかFinallyのどちらかひとつに
なんかアクティビティを入れろや

と怒っているので～～～～
RobotMainにReadConfigでの実行エラー結果を返せるように

代入アクティビティを

てな感じで選んでから

てな感じでセット

で作った

ロボ実行結果の引数を左辺に

てな感じで、右辺には、

"ロボットが異常終了しました。詳細はエラーメッセージを確認してください。"

セット完了

Mainを選択して、実行

コイツな

さっきと違ってエラーダイアログの表示なし( ´∀｀ )

てな感じで、エラー発生時のメッセージまで
消えてしまうので～～～

さっきの右辺の値を

コイツ

exception.Message

に変更してあげるだけで～～～

てな感じで変更できる

とここまでは例外処理における基本でExceptionを使ったけども( ´∀｀ )

前回ゆーたとおり、エラーには大きく分けて

ビジネスエラーとシステムエラーがあるので～～～

ちゃんとビジネスエラーかそれ以外か
を分けてあげる方が現実的( ´∀｀ )

さっきのままだと

ビジネスエラーだろうが、
システムエラーだろうが、
使い分けが出来ないからね👀💦

で、再度実行しても

さっきと処理結果は同じ( ´∀｀ )

これを最初からステップインして要所要所をキャプチャしてくと👀

左上のローカルに色んな値が入りながら、ReadConfig.xaml呼び出しまで進んだところ

フォルダの存在確認の実行直前

ローカルのPathに誤ったフォルダパスが入っている
ことを確認

ちゃんとElseに入ってんね

ここでステップインをもう一回すると
図のようにエラー発生

何度かステップインをクリックすると、
Catches＝例外の方に進んで
しっかりビジネスエラーの方に入った
ことが確認出来るね👀

でさらに進むと、Mainの最後まで
きちんと実行出来たのが分かる( ´∀｀ )

出力もこんな感じ( ´∀｀ )

ここでポイント②：なんでこんな面倒なことしてんの❓👀失敗するとダイアログボックスで画面表示されるからそれで良くない❓👀

理由としては２つ

1. エラーが発生したときも、専用の実行ログに残したいみたいな処理を入れたいときに困る

2. ロボットを完全自動化したときに、人が画面なんか見ないでロボットが定期的に時間がきたら実行するだけだから

☞いくら画面にエラーの内容なんざ表示しても、
そもそもパソコンの前に人が必ずしも張り付いていない
てか、せっかく自動化してんのに、
人がPCの前に必ずいないといけないんだったら
自動化の意味ないじゃん( ´∀｀ )

業務でロボットを利用してる人は、

• OC上のジョブログか専用の実行ログで処理が確実に終わったかどうか

• エラーがあった場合は、エラーから次に何をする必要があるか

くらいしか、

知識もないし、作れないし、
気にしなくていいんだから( ´∀｀ )

てか、知識もあって、作れて、エラー原因も自分で調査して改修出来るなら

そもそも、自分で作るだろ( ´∀｀ )
エンジニアが何のために存在するか
を考えろや( ´∀｀ )

ここでよもやま：教科書どおりの駆け出しちゃんで本当によくやらかすんだけど

ココのFinallyに簡単な
メッセージをログを追加してみよう

てな感じでどーでもいい戯れ文章( ´∀｀ )

でMainから実行すると、

ビジネスエラー発生

フォルダのパスを戻して～～～

Tryに入れたコイツな

変更後

で正常処理＝Tryで通るはずなので、実行してみると

正常処理でも出てきてる

そ、つまり

Finallyに入れちゃうと、
正常かエラーかにかかわらず、
必ずその処理は通っちゃう( ´∀｀ )

これを知らないか肌感覚で分かってないと、

エラー拒否症候群

な人ほど

• アクティビティの構成がこうなっている

• 隙間とか空欄箇所があると処理漏れとかエラーが発生しちゃうんじゃないか

と、

ついついFinallyに余計な処理を入れて、
却って、余計なエラーや想定外の処理結果
を発生させる( ；∀；)

ってなっちゃうからねえ。
こんな初歩的なミスを何年も繰り返してるのに、

自称プロの多いこと、多いこと( ´∀｀ )
（個人的には毎回遭遇する度に、「バカなの❓👀」
て思ってることはココでは内緒にしとく）

エラーハンドリングの基本：Try-Catchのまとめ

• Try：正常処理（この中でエラーがあれば例外にスロー）👈必須

• Catch：例外処理（例外＝スローされたエラーをキャッチ）👈必須

• Finally：正常であろうと、例外であろうと必ず最後に処理される👈任意。必要な時以外、処理は入れない。

だからオイラも今回のタイトルとか前回の最後で、

トライキャッチ

とはゆーてるものの

トライキャッチファイナリー

とはゆーてないでしょ( ´∀｀ )ここをよく理解してなくて、

「いやいや、トライキャッチじゃなく、
トライキャッチファイナリーでしょ。」

みたいな自称ちゃんもいるが、
（いや、ファイナリーはほぼ使わないから、みんなトライキャッチてゆーてるんだが、逆に教科書丸暗記な自称プロな人かな👀💦❓）
て思うのもココでは内緒にしとく💦
内容は以上。さてと、後は恒例の

ソース・リファクタリング

■リファクタリング前

シンプル過ぎる( ；∀；)

■リファクタリング後

正常処理

ビジネスエラー

Finallyのアクティビティは削除

関連記事：シーケンスについては、

なんかで、StudioXではあるけど、過去に遊んでるから参考にしてみてね～～～

さてと、次回は

フォルダの確認まで出来たところで、今度は

Configファイル自体の確認をする
☞ファイルの存在を確認アクティビティ

をやってく💃前々回～今回までで考え方も説明してるので、サクサクやってく( ´∀｀ )まあどうせ、

よもやま話は長くなるだろうが( ´∀｀ )
じゃ、また来週
ジム行って文藝春秋の続き
を読んで寝まする( ´∀｀ )