【いきなりStudio９】Throwアクティビティでガチろう～ガチりとは、いかにスローさせるかで決まると言っても過言ではない( ´∀｀ )。教科書通りの人のエラーはただ、エラーを通知するだけ( ´∀｀ )
さてと、
でも書いた通り、半年間で記事も増えてきて、前回の記事を追いにくいなと思ったので、
マガジンを独立させて、新装開店１発目💃
以外は、
日々の戯れにUiPathの記事を書く
これまでのスタイル
が何ひとつ変わることはない( ´∀｀ )
んだば早速～～～
Throwアクティビティ
してみたんだが、
意外といい記事がない( ´∀｀ )
まあ、当たり前すぎてってところもあるし、UiPathの公式ドキュメントだと、最初にヒットするのが
なんだけど、
Throwについて触れてないんだよなあ( ;∀;)
コミュニティでも
これくらい( ´∀｀ )なので～～～
ここでポイント①：まずはThrowって何？
イメージとしては、
正常処理の途中で、何かしらのエラーが発生した場合に例外処理（Exception：例外）に処理を投げる（Throwする）
☞Throw（スロー）
ってゆーてるだけ。なので、UiPathにかかわらず、どんなプログラミング言語の各現場でも、
「え？だったらスローさせたら良くない」
「ここは確実にスローさせとかないと後から起きたときに、、、」
って感じで日常会話の中でも頻繁に出てくるから、今後、開発現場で就職とか考える人はスローってそういう意味なんだくらいで覚えといてね～～～
ここでポイント②：そもそもエラーってどんなものがあるの？
なんかでも薄く書いてはいるけど、
業務を前提としたエラーとしては、大きく２つ
想定内エラー：ビジネスエラー
想定外エラー：システムエラー
業務を前提にかかわらず、開発作業で発生するエラーについては、
それは自分たちで直して、
リリースするのが当たり前
（例：アクティビティの設定ミス、
コードの編集でのコードミス）
そこはエラーとは言わないかな( ´∀｀ )
ゆーてたらキリがないし、そんな状態でお客さんに出すなや( ´∀｀ )
って当たり前の話なんで。
ここでポイント③：ビジネスエラーとシステムエラーはどう違うの❓👀そもそも、想定内と想定外って何❓
これは、前回
でゆーてたフォルダの存在なんかが分かりやすいと思うんだけど、ロボットをひとつ実行するにしても、
色んなファイルを参照する
色んなフォルダを参照する
WEBページやシステムと連携して、色んなボタンをクリックする、文字を取得する
Excelの各シートを操作する
取得したデータの値を参照して、処理をする
など、
色んなファイルやフォルダ、画面、値なんかが絡んでいる
と、当然、
普段の業務で対象のフォルダやファイルを扱う担当者が、操作ミスなんかでフォルダやファイルを消してしまう
対象のWEBサイトがサイレントアップデートで、ボタンの名前や位置まで変わってしまう
システムのエラーで出力した一部のデータが空（Null）で、値がうまく取得できない
なんてことが起こりうるし、そんな人為的なミスや変更以外でも、定期的な部署異動や年度が変わって、
フォルダやファイル自体が移動した
フォルダやファイルの名前が変わった
変更しないといけなかったのに、変更しておらず、前年度のフォルダやファイルで処理してしまった
などは、
業務の中では全て、起こりうる事象＝想定内
そんなビジネス上で想定内の事象を予め見越して対処（ハンドリング）を入れてないロボットだと起こりうるエラーだから
想定内エラー＝ビジネスエラー
以外でも、一時的な障害なんかで、普段使っている
インターネットが繋がらない
サイト自体が開かない
システムの画面が開かない
などなど、
想定できないシステム上の障害
なんかが起因のエラー
だから
想定外エラー＝システムエラー
まあ、これから操作で紹介していく中で、
実は、全てException＝例外エラーってだけで、
エラー処理を全て一括りにできなくはない
んだけど、それをやると、却って、
不測の事態が起因のエラーなのか否か
の切り分けが出来なくなる
☞原因追及（＝要因分析）が複雑になる
ので、操作前の前置きが長くなったけど、
大きく分けて２つあって、
それぞれの対処方法を場合分けする
ってことだけ、ここまでではイメージしてもらうといいかなあ( ´∀｀ )
じゃあ、今回はすっげえ簡単な操作を通して、エラーを実際に見てく💃
前回のソース
フォルダの存在を確認して、
ってところまで確認した続きで～～～
フォルダが存在する＝Trueの時は、正常処理（Then）
フォルダが存在する＝Trueの時は、エラー処理（Else）
って感じで条件を指定したいので、前回作った変数
mKakuConfigFolder = True
で、処理がどちらを通っているかを都度確認できるように
メッセージをログを追加して
ログレベルをInfoに～～～
ここまでで、ロボット上のエラーは消えたので、
ブレークポイントを入れて、
を通っているのが確認出来たね👀
さてと、ここからが今回の本題：実行結果でElse＝Falseに通すために
まあ、やり方は
フォルダ自体を移動する
フォルダの名前を変える
指定したフォルダパスを変える
などなど、やり方はいくらでもあるんだけど、今回は３番目が戻すだけで一番楽なんでそっちを採用
（変更前）
"C:\Users\USER\OneDrive\デスクトップ\プログラミング関係\Uipath関連"
↓
（変更後）
"C:\Users1\USER\OneDrive\デスクトップ\プログラミング関係\Uipath関連"てな感じで
再実行すると
ここで、エラー発生時に、メッセージのログを入れても意味がないと分かるよね👀💦なので～～～
今回は、ビジネスエラー（想定内エラー）なので
new BusinessRuleException("Configフォルダが確認出来ませんでした")
再度実行してみると
さっきとエラーメッセージも変わったのが分かるよね～～～
一歩前へ：エラーメッセージは誰のためのモノ❓
さっきのThrowをはめ込む前の赤文字エラーだと、
エラーが発生したことと、システムなりのエラー原因の解説までは書いてくれてるけど、それを読んだところで、慣れてる人じゃないと何をしていいか分からない( ´∀｀ )
今の”Configフォルダが存在しません”エラーだと、
エラーの原因が何かは分かるけど、業務で使っている人は、何をどうしていいか分からない。
エラー通知って別に、開発してる人のためだけにあるのではなく、
業務で使ってる＝開発知識がない人
が確認するためにも存在する
訳だから、
実行結果がエラーになった
実行ログを確認した
エラーがここで発生したのは分かるけど、だから何❓👀💦どうしたらいいの❓
ってならないで良いようにするのが、当たり前の配慮であり、思いやり。
ここで想定されるエラー原因としては、
パスに指定したフォルダが存在しない
指定したパス自体が書き変わっている
のいずれかしかない。でその内、
お客さん自身がフォルダパスを書き換えてしまってるなんてことは、開発者と利用する人が違う場合には、なかなかあり得ないので、
指定したパスのフォルダが存在しない
しかないんだから
new BusinessRuleException("Configフォルダが確認出来ませんでした。Configフォルダが存在するかを確認してください。")
で、
何をしたらいいかまで、書いてあげる方が
親切ってか普通( ´∀｀ )
ここでよもやま話：過去の現場で実際に、
教科書どおりの自称さんで、教科書のサンプル例を鵜呑みにして
にしてるソースを山ほど見たことあるんだけど( ´∀｀ )エラーメッセージを
ビジネスエラーが発生した☞ビジネスエラー発生
システムエラーが発生した☞システムエラー発生
って全部括っちゃうと、
「うん。だろうね。だから実行ログを見て、原因と何をしたらいいかを知りたいんだけど、こんなんソース見てわかる人が見ないと分からないじゃん。コイツらうちらの業務分かってんのか❓(# ﾟДﾟ)」
てことになるんだよねえ( ´∀｀ )
如何に、実際に使う人の
業務内容
UiPath に関する知識
ロボットの運用方法
なんかを把握して
エラーを上手に使いこなすかが大事
か分かるでしょ。
さてと、じゃあここで元に戻して恒例の
ソース・リファクタリング
リファクタリング前とリファクタリング後で今回は見せるや( ´∀｀ )
■リファクタリング前
■リファクタリング後
余計な確認用のメッセージをログを削除して、アクティビティ名を変更し、注釈を追加した程度( ´∀｀ )
めっちゃシンプル( ´∀｀ )
自画自賛( ´∀｀ )
もう一歩前へ：Throw処理をはめる箇所をソース全体で統一させる
ひっじょ～～～～～～～～～に、これも多いんだけど、
条件式の書き方によっては、
エラーがThen、正常がElse
って場合が出てくるから、
安易にただ闇雲に
条件式でやりたいことが処理できればいいや
で、
ある時は、正常がThen
他の時は、エラーがThen
ってあべこべでぐちゃぐちゃなソースを組んじゃう人も居るんだけど、
そんな人やそれを許してる組織に限ってロボ手順書なんかを用意もしてないから、ソースを調査するときに
読みにくくて仕方ない( ´∀｀ )
それでもソースを読んで理解するのがプロとか自称さんほど豪語するんだけど、裏を返すと、
本当の職人であれば、そもそもそんな読みにくいソースなんか組まない
余計な改修コストがかかるから( ´∀｀ )
☞だから、君たちは一生、
自称さんで終わるのだよ( ´∀｀ )
コードにしろ、ソースにしろ
自分以外の第三者が触れる可能性のあるものは、読み物
＝デザイン
☞読みやすさ、解析しやすさを意識する
人は読みにくいものは読もうとしないし、それでも読もうとすると、読み違えやミスを増発する
☞ミスする人が悪いのではなく、
「デザインが悪い」
ま、こーゆーことをテクニカル系の記事で書くと、
「自分はデザイナーじゃなくエンジニアなんで関係ない」って一蹴するような人や部署ほど
最初から当たり前に配慮しておけば
起きない障害や人的ミスで
今日もどこかで炎上してる( ´∀｀ )
ここでポイント④：なんでStudioXの時には出てこなかったの❓👀
ま、これも簡単な話だし、StudioXの記事で結構話してるんだけど、
そして、開発者に✓を入れて使えるようにしたところで、
・ブレークポイント
・ローカルエリア
などなど、
エラー解析に使える便利な機能が
StudioXには存在しないから
ま、この点について詳しくは、
でまとめてるつもりだから参考にしてみて～～～( ´∀｀ )
ここでポイント⑤：Studioでガチる場合は下へ下へ
で
StudioX。特にモダンの処理は、
下へ下へではなく、内へ内へ
って書いたんだけど、それは偏えに
StudioXの開発では、
Throw
（エラーが起きたときにロボットをコカす）
が無かったから( ´∀｀ )
そんなもんで、不用意に下へ下へ組んじゃうと、
エラーでコケないといけない処理が続いてしまう
下に流れるはずの処理が途中でエラーになぜかなる
て感じで
正常処理の場合のみの実行継続が難しくなる
し、ソースを見ただけでは、
何が正常処理なのか分からなくなっちゃうから
と、Throwについては以上。
さてと、次回は
throwで安全にロボットがコケた後の作法
Try-Catch
についてやってく～～～💃
Try-Catchこそ、ガチラーの嗜み
ちょっとオムライス食い過ぎたから夕方まで多分連投するや( ´∀｀ )
ではまた次回( ´∀｀ )