6

私はチェックされていない質問とチェックされた質問について読んできましたが、違いと両方をいつ使用するかについて本当に明確なオンラインリソースはありません.

私が理解していることから、どちらも実行時にスローされ、両方ともロジックの予想される範囲外のプログラム状態を表しますが、チェックされた例外は明示的にキャッチされる必要がありますが、チェックされていない例外はキャッチされません。

私の質問は、議論のために、2 つの数値を除算するメソッドがあるとします。

double divide(double numerator, double denominator)
{    return numerator / denominator;    }

とどこかで分割が必要な方法

void foo()
{    double a = divide(b, c);    }

分母がゼロのケースをチェックする責任は誰にありますか? また、例外をチェックするかチェックしないでください (Java の組み込み除算チェックを無視します)。

したがって、除算メソッドはそのまままたはとして宣言されますか

double divide(double numerator, double denominator) throws DivideByZeroException
{
    if(denominator == 0) throw DivideByZeroException
    else ...
}

void foo()
{
    try{
        double a = divide(b, c);
    }
    catch(DivideByZeroException e)
    {}
}

またはチェック例外なしで、そのまま：

double divide(double numerator, double denominator)
{
    if(denominator == 0) throw DivideByZeroException
    else ...
}

void foo()
{
    if(c != 0)
       double a = divide(b, c);
}

foo がゼロ除算のチェックを行えるようにしますか?

この問題はもともと、ユーザーが数値を入力し、論理クラスが計算を実行する、私が書いた数学プログラムで発生しました。GUI が不適切な値をすぐにチェックする必要があるのか​​、それとも内部ロジックが計算中にそれらをキャッチして例外をスローする必要があるのか​​ どうかはわかりませんでした。

4

6 に答える 6

7

確かに興味深いトピックです！

一般的なエラーと特に例外に対処する多くの方法を読んで試した後、プログラマーのエラーと予想されるエラーを区別することを学びました。

プログラマーのエラーは決してキャッチされるべきではなく、クラッシュ (!) が早く激しく発生します。プログラマ エラーは論理的な障害によるものであり、根本原因を修正する必要があります。

予想されるエラーは常にキャッチする必要があります。また、予想されるエラーがキャッチされた場合、ユーザーにメッセージを表示する必要があります。これには重要な意味があります。予期されるエラーがエラーを表示しない場合は、メソッドをスローさせるのではなく、メソッドがスローするかどうかを確認することをお勧めします。

あなたの例に適用すると、「これはユーザーにどのように見えるべきですか?」と思います。

  1. エラー メッセージを (ブラウザー出力、コンソール、メッセージ ボックスに) 表示する必要がある場合は、例外をスローし、できるだけUI の近くでそれをキャッチして、エラー メッセージを出力します。
  2. エラーメッセージが表示されない場合は、入力をチェックしてスローしません。

余談ですが、私は決して投げDivideByZeroExceptionたり投げたりしませんNullPointerException- 私は JVM にそれらを投げさせます。この場合、独自の例外クラスを作成するか、適切な組み込みのチェック済み例外を使用できます。

于 2011-02-21T20:53:06.580 に答える
1

数学演算の結果としてチェック例外がスローされるとします。例：部門（あなたの投稿による）。
これは、すべての整数除算が try ブロックに表示されることを意味します!
実際、除算は非チェック例外である ArithmeticException をスローする可能性があるため、キャッチする必要はありません。これは発生した例外的な状態であり、通常はコード修正
によってのみ解決できるため、実際にはキャッチしないでください。 あなたの場合、コードは実際にゼロで割る前に何かをしておく必要があります。

実際にゼロ除算を行うステップに到達した場合、できることは何もありません。プログラムに誤りがあり、例外をスロー/キャッチして何か偽装しようとするよりも、修正するのが最善です

于 2011-02-21T21:02:08.817 に答える
1

Java の例外はコンパイラによってのみチェックされますが、Java の設計者はそれらを複数のカテゴリに分割することを決定し、基本的にはスーパークラスを拡張することにしました。

  • java.lang.Exception- チェック例外と呼ばれる
  • java.lang.RuntimeExceptionUNchecked 例外として知られています - おまけとして java.land.RuntimeException は java.lang.Exception を拡張します (catchブロックでの処理を容易にするだけでなく)
  • java.lang.Error- エラーもチェックされておらず、ユーザー空間コードで処理する必要はほとんどありませんが、それらとその差異を知ることは大きなプラスです。それらには (最も有名なもの) が含まれます: リンケージ エラー、stackoverflow、メモリ不足、アサーション エラー
  • java.lang.Throwable-チェックしました！すべての例外の母であり、直接サブクラス化する必要があるものはほとんどありませんが、未知の理由でサブクラス化するものもあります

したがって、例外を宣言し、適切な伝播を処理する必要があります (コンパイルのみのレベルで)。

チェックされたものは一般に発生することが予想され、Java で余分な冗長性が必要になり、すでにふわふわしたコードになります。

ワースト プラクティスには次catch (Throwable t){}のようなものがあります。さまざまな理由から、通常、エラーは必要な場合を除き処理されません。ほとんどのエラーは通常、どちらの方法でもスレッドの死を意味します。

于 2011-02-21T20:44:34.323 に答える
1

Java におけるチェック済み例外と非チェック済み例外の哲学の違いに関する私のお気に入りの議論:

http://www.javapractices.com/topic/TopicAction.do?Id=129

于 2011-02-21T20:35:52.213 に答える
0

いくつかの長所と短所が挙げられているので、簡単に答えます。それは、個人または組織のスタイルの問題です。機能的に優れているものはありません。あなた (またはあなたのプロジェクト) は、チェックされた例外とチェックされていない例外、またはその両方を使用するかどうかについて、独自の決定を下す必要があります。

Oracle の Java チュートリアルでは、アプリケーションが回復できるすべてのエラーに対してチェック例外を使用し、アプリケーションが回復できないエラーに対して非チェック例外を使用するようアドバイスしています。しかし、私の経験からすると、ほとんどのアプリケーションはほとんどの (おそらく起動時ではない) 例外から回復する可能性があります。失敗したアクションは中止されますが、アプリケーションは存続します。

チェックされた例外またはチェックされていない例外のみを使用したいと思います。混合すると、混乱や一貫性のない使用につながる可能性があります。実用的であること。あなたの状況で意味のあることをしてください。

于 2011-02-21T21:02:36.333 に答える
0

明示的に s をスローしないでくださいRuntimeException。必要があると思われる場合は、を使用するのではなく、ランタイムに任せてくださいthrow。

于 2011-02-22T02:29:22.833 に答える