-3

カスタム例外クラスであるクラスを作成しましたが、これには多くのオーバーロードされたメソッドが含まれています

public class abcException extends Exception
{}

上記のabcExceptionクラスもインポートする別のクラスがあります

import com.system.error.abcException;
class fgh
{

void dhj() throws abcException //method that might throw Exception
{
try

{
}
catch(Exception bse) {
      log.logError(bse.getMessage(), bse);
      throw new abcException(bse.getMessage(), bse);
}
}

今私のクエリは、上記のクラスに示されているように、カスタムExceptionをスローする可能性のあるdhj（）という名前のメソッドが含まれているということですが、catchブロック内で、ロギング後に再び例外をスローするのはなぜですか？アドバイスしてください。そのようなものがあってもなくても大丈夫ですか？

4

4 に答える 4

2

そのような慣行は受け入れられます。SQLiteやMySQLで動作するデータベースドライバーを作成するときの例を考えてみましょう。クラスのパブリックAPIにはメソッドがありますconnect()。接続パラメータが間違っているために接続を確立できない状況を処理したいとします。ここでは、SQLiteとMySQLの動作方法に根本的な違いがあります。SQLiteはファイルベースであり、おそらくキャッチしますがFileNotFoundException、MySQLはネットワークからアクセスされ、を取得できますConnectException。MyDbDriverConnectExceptionパブリックAPIユーザーは、ドライバーの奥深くで何が起こったのかを知りたくないので、これらの例外を、処理がより便利だとしましょう。

UPD：例外のログに関しては、1つの例外が複数回ログに記録される状況が発生するため、ログと再スローはお勧めできません。詳細については、このすばらしい投稿をお読みください。

于 2013-01-06T07:24:46.780 に答える
1

throws句を使用している場合は、同じメソッドで再度キャッチする必要はありません。そのメソッドを使用するクライアントは、その例外を明示的に処理するか、throws句に再度配置する必要があります。ある時点で、誰かがその例外を処理する必要があります。コンパイルされません。この場合、キャッチアンドスローは冗長だと思います

于 2013-01-06T07:11:59.093 に答える
0

log と throw はしばしばアンチパターンと見なされます。http://today.java.net/article/2006/04/04/exception-handling-antipatterns#logAndThrowを参照してください。

catch (Exception e)通常、この方法はキャッチされるべきではない RuntimeExceptions をキャッチするため、悪い方法です。通常、チェックされた例外のみをキャッチします。Java 7にはマルチキャッチ機能があることに注意してくださいcatch(FirstException | SecondException e)

catch と rethrow については問題ありません。例外の変換です。http: //www.javapractices.com/topic/TopicAction.do?Id=120 を参照してください。

于 2013-01-06T07:48:23.473 に答える
0

例外の場合

  1. それをキャッチしてログに記録します。また
  2. 投げて

同じ例外をログに記録して再スローしないでください。

例: Java サーブレットでは、サーブレット メソッドは ServletException または IOException のみをスローできます。

したがって、ロジックで他の例外が発生した場合は、その例外を ServletException でラップして再スローExceptionします。これにより、ほとんどの場合キャッチされるはずのない RuntimeExceptions もキャッチされます。

于 2013-01-06T07:36:45.027 に答える