28

ランタイム例外は、(NPE などの) 壊れたコントラクトを示しており、コードにエラーがない場合は決してスローされるべきではありません。常にコード内のエラーを示します (アサートと同じですが、アサートは内部クラス エラー用であり、ランタイムはクラスのクライアント エラー用です)。

実行時例外は決してキャッチされるべきではありません。

一方、チェック例外は署名の一部であり、キャッチして処理する必要があります。これらは、ユーザー入力エラーまたは外部リソースの問題 ( などIOException) を示している可能性があります。

そのすべてで、なぜNumberFormatExceptionランタイムなのかわかりませんか?

4

6 に答える 6

10

まず、あなたに言った人は誰でも

実行時例外はキャッチされるべきではありません

Javaについてはよくわかりません。彼らの言うことを聞かないでください - 彼らは間違っています。

実行時例外である NumberFormatException:プログラミング エラーを示すため、未チェックの例外が選択されます。Stringが有効な整数であることを (たとえば)呼び出す前に知ることができます。たとえば、次の 1 つの方法があります。Integer.parseInt()

if (str.matches("^\\d{1,8}$") {
    int myInt = Integer.parseInt(str); // will never throw NumberFormatException 
}

したがって、エラーが発生することはプログラミング エラーと見なすことができます。プログラマーは最初にチェックしないことを選択しました。

解析しようとしている文字列の整合性/品質に自信がない場合は、簡単にキャッチできます。

try {
    // parse your string
} catch (NumberFormatException e) {
    // do something about it
}

これをランタイムにするもう 1 つの理由は、不要な可能性のあるブロックでコードが乱雑にtry/catchならないようにするためです。たとえば、文字列データのソースを完全に信頼する場合など、不要なブロックを取得しないと確信している場合です。

于 2011-08-26T13:51:43.713 に答える
2

NumberFormatException構成ファイルを解析するときにもスローされる可能性があり、その場合はプログラマーのエラーになります。ユーザー入力を解析するとき、通常はNumberFormatwhich を使用して、checked をスローしますParseException。

于 2011-08-26T13:53:41.060 に答える
1

NumberFormatException は IllegalArgumentException を拡張します。これが実行時例外である理由は、 を受け取ってStringを返すメソッドのコントラクトを完全に破ることができるためNumberです。私が渡し、123Dデータの適切な検証がない場合、これは適切な不正な引数になります。

于 2011-08-26T13:52:09.163 に答える
-1

NumberFormatException が実行時エラーになるのはなぜですか? ユーザーが値を入力するダイアログがあり、その値が数値ではなく、そのように解析される場合は、それについて知りたいと思うでしょう。例外は最善の方法ですか? そうではないかもしれませんが、それはそれが何であるかです。

于 2011-08-26T13:51:22.837 に答える
-2

ある意味でNumberFormatException は、コンパイル時の例外です。ただし、Java コンパイラによってスローされるのではなく、プログラムの実行時に書式文字列パーサー/コンパイラによってスローされます。Pattern同じことが正規表現のその他の使用法にも当てはまります。あなたのプログラムはパーサー/コンパイラーを実行しています。

于 2015-11-15T19:29:36.847 に答える