C# 間違えるって素晴らしい！ 例外処理の話
はじめに
C#の開発には、UI/UXベースで分けるとForms、WPF、UWP、ASP.NETなどありますが、実装がそこそこできるようになると、担当する範囲や面倒みたり気にしたりする箇所も増えてきます。
しかし開発対象が複雑になっても基本的な事が変わらない個所がいくらかあります。
- DBアクセス
- ネットワーク接続
- 例外処理
今回は、この例外処理について記述します。
1.基本仕様が決まって詳細設計へ
この段階になると、実装を意識した構想が具体化してきます。
映画やTVドラマなんかだと、シーンや配役、見どころなどを詰めているあたりですね。
機能や役割が明確になってくる
各クラスの機能、その役割から振る舞い、持ち物（データ）が決まってきて
処理の見せ場や主要機能がつながってきてデバッグも面白く歯ごたえのある段階に入ってくると
実装ミスも発見したり、仕様漏れも発見する忙しい時期に入ります。
実装部分のテスト仕様書を記述する
さて、この段階こそがエンジニアとして本当にキツイ状態になってくると覚悟してください。
2.「間違えること」について
実装ミス、仕様漏れ発見などテストが順調に進んでいくのはいいです。
ここで、他にも不具合要因があると予測して把握しているか説明できますか？
次の内容を自問自答してみよう！
「正常系、準正常系、異常系はどれだけ想定して対応できている？」
- 正常系 ・・⇒ これは仕様を満たせばいいか、、
- 準正常系 ・・⇒ これは仕様のなかでも0、-1、null、空白でみたらカバーできる
- 異常系 ・・⇒ 計算式のゼロ割とかnull参照は想定できるとして、なんか他は不安、、、
最後の異常系の網羅や想定範囲、本当にC＃の想定をカバーできるか不安になりませんか？
数多のライブラリ、その実装の詳細は見えないので例外のカバーできているか把握するは難しいのです
また、過去のDLLを使ったり、自分のモジュールや開発した部品を利用される側に立ったとき、
仕様通りの動きに加えて、仕様通りのエラー処理になるか、その情報を伝達できるかまで
設計に入っているか、後工程のユーザーに便利になっているか想定できているでしょうか？
3. 思わぬ間違いと、想定された間違い
映画やTVドラマの話をだしましたが、たまにNGシーン集の番組があったりしますよね。
見ている方は思わず笑ってしまいますが、流れを作成している編集さんは撮影の流れを止めないといけないシーンが発生しています。
まさに、C#でも他の言語でも例外というのは、流れをぶった切る継続できないNGが発生したものなんです。
例外発生
特に動作確認時に「～Exception発生！」などと言われても初学者にとっては
何がどうしたらいいのか、また原因すらわからないと思います。
酷いときには、突然「一般保護例外！」などと表示されたあとでユーザーは何をどうしていいのかわからないままOSが勝手にダウンして再起動する時代もあったんです。
思わぬ間違いで不具合を起こさないために
予想されない動作は、操作している人や管理している人に負担が増えます。
仕様にもよりますが、ユーザーのコンピュータスキルは初心者レベルを想定すべきでしょう。
ドラクエなら、いきなり序盤のフィールドでエスタークに会うようなものですから。
誰だって「なにこれ、ちょっと待ってよ、、、」となります。
英語圏の人なら、This App is a lemon.
（意味：このAppは欠陥品）と思われて印象悪いでしょう。
だったら、発想を変えてみよう
間違いはダメなものだけど、いつ起きるかわからないから対応しようがない。
この考えを変えるためには、積極的に間違った考えを持ってみることです。
間違いは起きない優等生的な実装ではなく、「間違えるって素晴らしい！」
という考えをもってアプローチすると、誤りや誤動作に対して管理されたロジックになるのでアプリケーションとして長生きします。
そこで、.NET Frameworkを真似てみてはどうでしょうか、
メソッドにマウスカーソルを当てると、コメントに記載された発生する可能性がある例外を表示します。
// 概要:
// Converts the string representation of a number to its 32-bit signed integer equivalent.
//
・・・
// 例外:
// T:System.ArgumentNullException:
// s is null.
//
// T:System.FormatException:
// s is not in the correct format.
//
// T:System.OverflowException:
// s represents a number less than System.Int32.MinValue or greater than System.Int32.MaxValue.
public static int Parse(string s)
{
throw null;
}
想定できるエラーを扱う
積極的にエラーを発生させて、その対応ができるようになると
仕様上でその記載を論理的に分類したり、名称を区別したりします。
「間違えるって素晴らしい！」 思想で作成されたエラーを「例外」としていて
他の処理でメモリがいっぱいで使えなくなったとか、HDDが故障寸前でアクセス不良おこしたとか
他責になるものを「エラー」と使い分けています。
例外をコメントに記載して論理的にコントロールできると
後から使うモジュールとしても信頼されます。何がおきるか範囲を想定できるのは安心できるからです。
おわりに
例外を上手に扱っていると、新人や初学者ではない目線を向けられることでしょう。
C#の機能がバージョンアップしても、誤りが混入して取り除く対応することは変わっていません。マウスカーソルをメソッドなどに当てるだけで例外が分かるのは本当に便利です。
是非とも、実装時の確認にはカンタンにできる方法なので、この〆の行為をお願いしたいところです。
Discussion