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

catch できない？
どういう事でしょう？

11.2.2　実行時例外を検査しない理由

実行時例外のクラス(runtime exception classes，RuntimeException
及びそのサブクラス)は，コンパイル時に検査されない。その理由は，
そのような例外を宣言させることは，Javaプログラムの正当性の確立を
大して援助しない，とJava設計者が判断したためである。
Java言語の演算及び構文の多くは，実行時例外を生じることができる。
Javaコンパイラが利用できる情報及びコンパイラが実行する分析の
レベルは，通常，たとえJavaプログラマには明白であるとしても，
それらの実行時例外が起こり得ないと証明するためには十分でない。
そのような例外クラスの宣言を要求することは，単にJavaプログラマを
苛立たせるだけだと考えられる。

例えば，あるコードが，その構造によって，決して空参照を
含むことがない循環的なデータ構造を実装したとする。
このとき，プログラマは，NullPointerExceptionは，
決して起こらないと確信できる。しかし，コンパイラがそれを
証明するのは，困難であろう。データ構造のそのような大域的な
特性を確立するために必要な定理証明技術は，
このJava言語規定の範囲を超える。

非チェック例外とは、「発生しないことを保証できるコーディングが可能な例外」

非チェック例外を catch するのは、よほどのことがない限りすべきではない

フォーマット検査を行わない値をいきなり数値変換するから「例外」が起こり得るわけ

NumberFormatExdeption を検査代わりに使うのは一種のSyntax Sugarと言えるかも。

おばけさんの書き込み (2003-11-17 22:42) より:

それよりも、Character#isDigitを使うとすると、Stringをいちいちcharの配列にしてループで回してやらないといけないのでしょうか？みなさんはどうやって判定されてるんですか？

さくらばさんの書き込み (2003-11-18 04:58) より:

コード:
String str = ...... str.matches("\d+");

でくのぼうさんの書き込み (2003-11-17 21:12) より:
さてさて、Java言語仕様の例外に関しての記述を読み返してみました。
http://www.y-adagio.com/public/standards/tr_javalang/11.doc.htm

(略)

さて、これを読み返したところで私の目からウロコが落ちました。
というのも私もKeisukeさんが言うように

引用:
非チェック例外とは、「発生しないことを保証できるコーディングが可能な例外」

と考えていたのですが「発生しないことを保証できない」からこそ
「非チェック」にしていた、と現実は正反対だったのです・・・。