So-net無料ブログ作成
検索選択

【Java】 例外は難しい ③

さて、ここで一つ、例外に関する処理を見てみたい。

 String strnum = [何らかの処理];
 int intnum = 0;
 try {
  intnum = Integer.parseInt(strnum);
 } catch (NumberFormatException e) {
  intnum = -1;
 }

果たしてこれは有りなのだろうか?
正直な話、私はこういうコードを書いたことが有る。
なぜなら「例外はキャッチして復帰すべき」と考えていたからだ。
そう、「例外は難しい ①」だけを読めばこの考え方は正しいと思う。

が、NumberFormatExceptionはRuntimeExceptionのサブクラスである。
「プログラマが発生しないことを確信できる」から強制的にキャッチやthrows節に書くことを免除されているのだ。
parseIntの説明にも「文字列内の文字はすべて、10進数の桁である必要があります。」と明示されている。
であれば、

 String strnum = [何らかの処理];
 [strnumが10進数であることをチェックする処理]
 int intnum = Integer.parseInt(strnum);

とするのがより良いようにも思える。
[strnumが10進数であることをチェックする処理]により「プログラマが発生しないことを確信できる」状態にする訳です。
さらにstrnum = [何らかの処理]の処理で10進数の整数を表現する文字列が確信できるのであれば

 String strnum = [何らかの処理];
 int intnum = Integer.parseInt(strnum);

でも問題ない訳です。
…のですが、、、
RuntimeExceptionがキャッチまたはthrows説に書くことがコンパイラに検査されない、というのは
キャッチすることが禁止されている…という訳ではないですよね。
なので「例外はキャッチして復帰すべき」という考え方も間違っているとは言いきれないのです。
上記3つのパターンのどれが最善かは最早前後の処理や規約で判断するしかなく、
これが例外をして難しいと言わしめる原因になっているのでは?と考える次第です。

個人的な見解としては、
NumberFormatExceptionは検査例外、つまり通常のExceptionのサブクラスであるべきだったのでは?と。
もしくはRuntimeExceptionであるのであれば、Integerに値検査用のメソッドがあるべきだったのでは?
と思う訳ですが、残念ながらそうはなっていないですね。

ちなみにintnumが復帰することが許されない…という状況も充分有りうるので1番目と2番目の処理において
チェックに違反した場合はErrorをスローすることも有り得るのかな…と。
コメント(0) 
共通テーマ:資格・学び

コメント 0

コメントを書く

お名前:
URL:
コメント:
画像認証:
下の画像に表示されている文字を入力してください。