- PR -

NumberFormatException が非チェック例外なのはなぜ?

«前のページへ 1|2|3|4|5 次のページへ»
投稿者投稿内容
ぽん
大ベテラン
会議室デビュー日: 2003/05/13
投稿数: 157
投稿日時: 2003-11-21 18:03
引用:

架空兎さんの書き込み (2003-11-21 17:17) より:

私の推測なのですが、NumberFormatException は IllegalArgumentException の
サブクラスであることから、Integer#parseInt メソッド等の引数には解析可能な文字列を
渡すことを前提としているのではないでしょうか？
＃例えば、数字しか入力されない項目から取得した文字列であれば例外をキャッチする
＃必要はないですよね？

もし、解析可能かどうか分からない文字列を解析する場合は java.text.NumberFormat クラスの
parse メソッドを使う、ということなのではないでしょうか？
＃ parse メソッドが発生させる java.text.ParseException はチェック例外。

それなら理屈に合いますね。
未記入
ぬし
会議室デビュー日: 2002/03/28
投稿数: 255
投稿日時: 2003-11-21 21:02
>チェックされる例外を投げられても、呼び出し側が何も対処出来るようなことがない
>ような例外なのにチェックされる例外を投げてる場面が多いんじゃないか？
ひょっとしてＪＳＰの話ですか？
もしそうならば，それはJSPの弱点(或いは欠陥)であって，例外の側の問題じゃないと思います．

>それなのにtry-catchまたはthrowsを書くことをコンパイラによって強制されて
>やんなっちゃうよっていうようなニュアンスなんだと思います。呼び出し側で対処出来なくて
一々全部書くのが面倒ってだけなら，
catch( java.lang.Exception e ){ }
とか書けば良いだけでは？
＃ダメでしたっけ？java.lang.Throwableさえ書けたとは思うのだが．．．

普通はやりませんけどね．
書き忘れが検出できるというのは重要ですから．
やまろう
常連さん
会議室デビュー日: 2003/10/13
投稿数: 35
お住まい・勤務地: 埼玉・東京
投稿日時: 2003-11-27 14:29
引用----------------
　　　　>チェックされる例外を投げられても、呼び出し側が何も対処出来るようなことがない
　　　　>ような例外なのにチェックされる例外を投げてる場面が多いんじゃないか？
　　　　ひょっとしてＪＳＰの話ですか？
　　　　もしそうならば，それはJSPの弱点(或いは欠陥)であって，例外の側の問題じゃないと思います．
JSPの話ではないです。たとえば、システム的な例外が起きたとして、仮にNamingExceptionが
起きたとします。NamingExceptionをユーザが作った例外SystemExceptionという例外にラップして
投げなおしたとします。もし、このSystemExceptionをチェックされる例外にしたとしたら、
この例外がとんできたクラスはtry-catchまたはthrowsを書かなければなりません。
システム的な例外を回復することなんて出来ないのでtry-catchするとしたらさらに新しい例外で
ラップして投げるくらいしかできないし、またはthrowsを書くにしても、ずっと呼び出し元へ
むかってthrowsを書き続けなければなりません。それって無意味じゃないですか？
なので、ここでいうSystemException(呼び出し側が何も対処出来ない例外)は
RuntimeExceptionにすべきだってことです。
呼び出し側が何も対処出来ないってのはそういう意味ざんす。

引用----------------
　　　　>それなのにtry-catchまたはthrowsを書くことをコンパイラによって強制されて
　　　　>やんなっちゃうよっていうようなニュアンスなんだと思います。呼び出し側で対処出来なくて
　　　　一々全部書くのが面倒ってだけなら，
　　　　catch( java.lang.Exception e ){ }
　　　　とか書けば良いだけでは？
　　　　＃ダメでしたっけ？java.lang.Throwableさえ書けたとは思うのだが．．．

　　　　普通はやりませんけどね．
　　　　書き忘れが検出できるというのは重要ですから．

一々全部書くのが面倒なんじゃなくて、無意味だってことです。catch( java.lang.Exception e ){}
と書いて全ての例外を補足してもすることがなくて、さらに呼び出し元に向かってラップした例外を
投げるだけでしょう。ただ、上に向かって投げてくしかないような類の例外はRuntimeExceptionに
すべきだと思います。



[ メッセージ編集済み 編集者: やまろう 編集日時 2003-11-27 14:33 ]
佐々木
大ベテラン
会議室デビュー日: 2003/03/30
投稿数: 121
投稿日時: 2003-11-27 21:49
引用:

ただ、上に向かって投げてくしかないような類の例外はRuntimeExceptionに
すべきだと思います。

賛成賛成。
僕はチェック例外って作ったことがありません。

今までどれだけ無意味な catch 句を見てきたことか。
こんなやつ。

コード:
catch(Exception e) {
  e.printStackTrace();
}

あと、retryの仕掛けがない try{}catch{}は価値が半減すると思うんですよ。
こんな風に書きたいです。(イメージです。深く考えてません。)

コード:
try(3) { //最大3回試行。
  //your code goes here.
} catch(SomeException e) {
  // 回復の試み
  retry;
}


Wata
ぬし
会議室デビュー日: 2003/05/17
投稿数: 279
投稿日時: 2003-11-27 22:35
引用:

やまろうさんの書き込み (2003-11-27 14:29) より:
ここでいうSystemException(呼び出し側が何も対処出来ない例外)は
RuntimeExceptionにすべきだってことです。
呼び出し側が何も対処出来ないってのはそういう意味ざんす。

わたしも賛成。
上に書いたEffective Javaの内容も同様のこと。
# 引用箇所が少なすぎて、あまり伝わってなさそうですが...

強いて言うと、むしろErrorを投げたほうがいいかもしれない。
アサーション的なものならjava.lang.AssertionError、
それ以外はただのjava.lang.Errorにcouseをつけて。

この方が、どっかでもみ消されることが少なくなると思います。

で、当初のNumberFormatExceptionは大抵の場合、ユーザー入力のパーズ時に発生します。
その場合、再入力を促すことにより回復可能です。
なので、NumberFormatExceptionはチェック例外でも構わないと思います。
おばけ
ぬし
会議室デビュー日: 2002/11/14
投稿数: 609
お住まい・勤務地: 東京都江東区
投稿日時: 2003-11-28 00:01
引用:

強いて言うと、むしろErrorを投げたほうがいいかもしれない。

前にどこかで聞いたのですが、Errorはユーザアプリケーションからは投げてはいけないのではないでしょうか？(根拠はありません。自分がやっていて、他の人に注意されたことがあったからです)
未記入
ぬし
会議室デビュー日: 2002/03/28
投稿数: 255
投稿日時: 2003-11-28 07:07
>むかってthrowsを書き続けなければなりません。それって無意味じゃないですか？
>なので、ここでいうSystemException(呼び出し側が何も対処出来ない例外)は
>RuntimeExceptionにすべきだってことです。
>呼び出し側が何も対処出来ないってのはそういう意味ざんす。
つまり，そのアプリケーション固有のセマンティクスにおいて処理する／キャッチする
必要のない場合に，そのアプリケーション固有の例外をどうするか，という話ですよね？
＃JSPの話でもなければJ2EEの話でもなく，あくまでJavaアプリケーションの実装
＃レベルの話．

例外をどう使うかが設計の一部だというのは，当たり前の話じゃなかったんですか？
未記入
ぬし
会議室デビュー日: 2002/03/28
投稿数: 255
投稿日時: 2003-11-28 07:11
>前にどこかで聞いたのですが、Errorはユーザアプリケーションからは投げてはいけないの
>ではないでしょうか？
＃多分，Errorのサブクラスという意味だとして，

>(根拠はありません。自分がやっていて、他の人に注意されたことがあったからです)
おそらく，禁止はされていないと思いますよ．

適切なErrorのサブクラスを定義して投げる分には問題はないと思います．むしろ
問題があるとすれば不適切なクラスを作ったり，ErrorでないものをErrorで投げたり
する場合でしょう．もちろん，なんでもかんでもErrorで投げるとすれば，それは
好ましいプログラミングスタイルとは言えないでしょうが．
«前のページへ 1|2|3|4|5 次のページへ»

スキルアップ／キャリアアップ（JOB@IT）