VB.NETの例外処理についての考察と備忘録

例外の処理について

プログラムを書く上では必要らしい例外処理。

まぁ、人間ミスはかならずあるものなので、いざというときにエラー発生箇所を掴むための保険的なところなのでしょうか。

ということで、色々調べては見ましたが、結局こう書いておけばいいという一般的な記載はなく、あるところでは例外処理は無くていいという記述も合ったような気がします。

そりゃ、例外が出るはずがない処理にわざわざいれる必要なんてないですもんね。それに、目的によって書き方なんていくらでもあると言いますから。

とりあえず、VB.Netですが、使い方等いろいろやってきて、備忘録として書きます。

これも一つの例としてとうことで。

プロジェクトは何でもいいですが、適当にWindowsFormでボタンを設置。

まずはメインのソース。

あとは別クラスでも検証用に作成しています。

関数や変数名が適当なのは気にしないでください。

ここで例外が出るところは変数「ggg」で、出現エラーはゼロ除算「System.DivideByZeroException」になります。

検証のためにそれぞれの関数に仕込んでいます。

動かしてみる

上記のメソッドを動かしてみるとこうなります。

エラーメッセージはそれこそ個人の自由ですが、今回は「クラス名:メソッド名:エラー行数」としています。

考察みたいなもの

まず、このプログラムにおける例外処理の決め事として、最終的なエラーメッセージ表示はボタンクリックイベントのメソッドで表示するということ。

ネストしたものは基本Throwして、上のメソッドに投げることを前提としています。

上記のイベントメソッドの中では「aaa()→bbb()→ccc()」と呼び出し、 ccc() の中のTry…Catch外で例外を発生させます。

結果として、ccc() のエラーがbbb()のCatchに入り、それがThrowされて、 さらにaaa()にもThrowされて、エラー表示されます。そして、その後のMsgBoxも表示されません。

ちなみに下記のようにすると。

ccc()の中の Try…Catch にエラー発生のコードを入れるとThrowがエラー行として出てきます。

ということで、「最上位でエラーを取得するやり方をするのであればという前提で」以下まとめます。

  • 最下層には Try…Catch は置かなくていい
  • Try…Catch 外のエラーが上位のメソッドでCatchされる
  • 別クラスでも同様
  • 最上位でのCatchなので、それ以降の処理はされない(Finallyで後処理は必要)

あと、今回のプログラムとは違い、それぞれのメソッドで例外をキャッチしたい場合は、Throwのことは考えなくていいかもしれません。

その代わり、例外メソッド以降の処理は続くのでそれでもいいプログラムならOKというところでしょうか。

これ、常識なんですかね。

この使い方で合っているのだろうか、相変わらず自信がないです…。

コメント

タイトルとURLをコピーしました