- PR -

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

«前のページへ 1|2|3|4|5
投稿者投稿内容
raccoon
ベテラン
会議室デビュー日: 2002/12/18
投稿数: 58
投稿日時: 2003-11-28 15:54
引用:

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


中には「やってはいけない」と主張する人もいるようです。↓
http://java-house.jp/ml/archive/j-h-b/010144.html#body

# わたしは出典元の書籍を持っていないので，著者の意図や
# この記述に至る経緯はわかりませんが･･･。
# どなたかわかる方がいらっしゃったらフォロー願います。

わたし個人としては，
『Javaの規則として禁止されてはいないが，
よほどのことがない限りやるべきではない』
という考えです。

おばけ
ぬし
会議室デビュー日: 2002/11/14
投稿数: 609
お住まい・勤務地: 東京都江東区
投稿日時: 2003-11-28 16:26
引用:

中には「やってはいけない」と主張する人もいるようです。↓
http://java-house.jp/ml/archive/j-h-b/010144.html#body

あ、私もこんな様なことを聞きました。その方は、「Errorはシステムエラー(つまりVM内のエラーということだと思いますが)の場合にのみ送出されるべき」と主張されていました。
かずくん
ぬし
会議室デビュー日: 2003/01/08
投稿数: 759
お住まい・勤務地: 太陽系第三惑星
投稿日時: 2003-11-28 16:52
Effective Javaにもちょこっとだけかかれていますね。引用すると、
引用:

JLS（Java言語仕様）は要求していませんが、JVMが実行を継続することができない資源不足、不変式エラー、あるいはほかの状況を示すために、エラーはJVMが使用するのに予約されているという強い慣習があります。

この分に続いて、非チェック例外はErrorから派生させるのではなくRuntimeExceptionから派生させることを薦めています。

[ メッセージ編集済み 編集者: かずくん 編集日時 2003-11-28 16:56 ]
unibon
ぬし
会議室デビュー日: 2002/08/22
投稿数: 1532
お住まい・勤務地: 美人谷　　　　　　　　良回答(20pt)
投稿日時: 2003-12-01 14:26
unibon です。こんにちわ。

引用:

架空兎さんの書き込み (2003-11-21 17:17) より:
もし、解析可能かどうか分からない文字列を解析する場合は java.text.NumberFormat クラスの
parse メソッドを使う、ということなのではないでしょうか？

＃以下、遅い反応ですが。
このクラスにパースの機能があるとは知りませんでした。ありがとうございます。
しかし、つぎのような場合("1d2")は、
DecimalFormat クラスのパースは成功するのですが、parseDouble は失敗しました。
コード:
import java.util.*;
import java.text.*;

public class NumberTester {

    public static void main(String[] args) {
        try {
            String s = "1d2";
            Locale l = Locale.getDefault();
            NumberFormat nf = DecimalFormat.getInstance(l);
            Number n = nf.parse(s);
            double d = n.doubleValue();
            System.out.println("d = " + d);
            double e = Double.parseDouble(s);
            System.out.println("e = " + e);
        } catch (ParseException ex) {
            throw new RuntimeException(ex);
        }
    }
}

＃そもそも DecimalFormat.parse を使うなら Double.parseDouble を呼ぶ必要はないのですが。

ちなみに、上記コードのように再スローすれば、
チェック例外から非チェック例外への変換はできますので、
チェック例外にするか非チェック例外にするか疑わしいものは、
チェック例外にしておくほうが無難なような気がします。
＃再スローは JDK の 1.4 から標準でサポートされましたが。
架空兎
ベテラン
会議室デビュー日: 2003/08/18
投稿数: 78
お住まい・勤務地: さいたま氏
投稿日時: 2003-12-01 15:52
引用:

unibonさんの書き込み (2003-12-01 14:26) より:

しかし、つぎのような場合("1d2")は、
DecimalFormat クラスのパースは成功するのですが、parseDouble は失敗しました。

Integer#parseInt や Double#parseDouble 等と違うところは、NumberFormat#parse は
解析できなくなるとそこで解析をやめて、解析された部分までの数値を返します（例外にならない）。
もし、厳密に解析する場合は NumberFormat#parse(String, ParsePosition) を使って
文字列の最後まで解析されたかどうかを判断する必要があります。
＃とても面倒ですが。。。
＃ちなみに、NumberFormat#parse(String, ParsePosition) は例外をスローしない。

コード:



public static Number parseNumber(String text) {

    NumberFormat format = NumberFormat.getNumberInstance();

    ParsePosition pos = new ParsePosition(0);



    format.setGroupingUsed(false);  // グループ化を使用しない

    Number number = format.parse(text, pos);

    if (number != null && pos.getIndex() == text.length()) {

        return number;

    }

    else {

        return null;

    }

}

私の見解としては、Integer#parseInt 等は数値を表す文字列をその型に変換することが目的で、
それらのメソッドの引数は必ず数値として解析できる文字列でなければならない、
（つまり、NumberFormatException を発生させてはならない）ということだと思います。
＃でも、文字列の解析に Integer#parseInt 等を使って NumberFormatException をキャッチした方が
＃ラクで、しかも速いんですけどね。＾＾；


[ メッセージ編集済み 編集者: 架空兎 編集日時 2003-12-01 17:09 ]

[ メッセージ編集済み 編集者: 架空兎 編集日時 2003-12-02 09:54 ]
unibon
ぬし
会議室デビュー日: 2002/08/22
投稿数: 1532
お住まい・勤務地: 美人谷　　　　　　　　良回答(20pt)
投稿日時: 2004-06-22 21:37
unibon です。こんにちわ。

半年前の話題ですが、最近、IBM のサイトで、
「Javaの理論と実践: 例外をめぐる議論
　チェックすべきか、チェックせずにおくべきか」
http://www-6.ibm.com/jp/developerworks/java/040618/j_j-jtp05254.html
という記事を見つけました。ご紹介まで。
«前のページへ 1|2|3|4|5

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