throw exとthrowは違うんだよ

C#例外処理でのthrowとthrow exの違い
「throw ex;」と書くと、本当の発生元の例外情報が消えてしまうのだそうで。
例外クラスを変えなければ、「throw;」が良いってことだな。
ところで、仕事上、「予期していない例外と開発者によってコード上でスローされる例外」を明確にしたい時がある。開発者によって投げられる例外って言うのは、「実行上では問題ないけど、業務上アウトな状態」が多い。例えば、

必須項目が入っていない
設定された値が、仕様で決められた範囲にない。
既に存在するキーで登録しようとする。

等。
で、よくやる手が、独自例外クラスの実装だったりする。
なお、独自例外クラスの実装は、上記理由の他にも、

例外内容がそのままを表示しても、ユーザは、次にどういうアクションを取れば良いのかわからない

時も、よく作成する。
この例外クラスに持たせる例外情報に必要なのが、

メッセージ
発生元の例外情報(例外をキャッチした時のみ)

となる、まあ、これは標準の例外クラスでも持っている情報。
ただ、この「エラーメッセージ」というところで悩むときもある。小さいプロジェクトや、開発ツール的な、表には出ないアプリなら、直接埋め込むの有りかなと思う。でも、規模が大きくなってくると、それではすまなくなる。
例えば、複数のクラスで同じメッセージで例外を発生させたい時とか。埋め込む分には、「コピペ」でOKなんだけど、変えるとなると大変になる。変えそこねるリスクが生まれる。
そんな理由から、メッセージはリソース化される事が多い。保管先は、データベースだったり、ファイルだったり、アセンブリリソースだったりするわけなんだけど、ユニークなキーを指定して、メッセージを取り出すという事に変わりはない。
という事で、上記2項目に加え、

メッセージキー(リソースキー)
サブメッセージ
メッセージパラメータ

等を加えて、エラー情報にする事が多い。
サブメッセージというのは、補助的なメッセージで、ユーザに次にこういうアクションとってねという情報を添えたり、このID、この番号がダメだよと知らせたりする。
メッセージパラメータは、メッセージを動的に変えたい時に使う。例えば、必須入力であるメッセージを作るとき、メッセージ本文は、

{0}を必ず入力してください。

で作り、状況に応じて、{0}に埋め込む文字列をパラメータとして持たせる、とか。
この独自例外クラスを標準の例外クラスと処理を区別しないと意味ないけど、まあ、それは気をつけるだけなんだよな。
スポンサーサイト
当サイトは基本をすっ飛ばしてます。基本文法等は、@ITをどうぞ
カテゴリー: C# | コメント: 0 | トラックバック: 0


この記事へのコメント

コメントの投稿

非公開コメント


サイドバー背後固定表示サンプル

当ブログに書かれたソースコードは流用自由です。

バグ、スペルミス等はありうる事です。

ご利用の際は自己責任でお願いしますm(_ _)m