8

独自の例外をスローするのが「悪い考え」なのはなぜですか?

ここで見つけた

4

10 に答える 10

23

一般に、独自の例外をスローしてもまったく問題ありません。おそらく、あなたが尋ねたかったのは、「自分の例外をスローすることが必ずしも良い考えではない場合はいつですか?」ということでした。

1 つのケースは、標準例外をスローする必要がある場合です。たとえば、メソッドがファイル名を受け取り、ファイルを返すことになっている場合、おそらく PeanutPowersFileNotFoundException をスローするのではなく、プラットフォームの標準の FileNotFoundException をスローする必要があります。本当に独自の例外をスローしたい場合は、おそらく標準の FileNotFoundException を拡張する必要があります。

更新: Bloch は、Effective Javaの Item 60 でこれを説明しています

于 2010-02-06T23:20:27.080 に答える
4

そうではありません。例外的な状況が発生した場合は常に、カスタム例外を作成してスローする必要があります。

于 2010-02-06T23:14:47.150 に答える
3

標準の基本例外タイプ (c++ の std::exception、Python の Exception など) から派生したものであるとは限りません。

それらが通常の基本型から派生していない場合、すべての例外をキャッチすることを期待しているときに、他の人がそれらをキャッチしない可能性があります。これは悪いことです。

于 2010-02-06T23:15:09.137 に答える
3

独自の例外タイプを作成することは間違いではありません。ただし、独自の例外を作成する前に、フレームワークが適合する例外を既に提供しているかどうかを確認する必要があります。

.Net 設計ガイドラインから:

カスタム例外タイプを作成する代わりに、System 名前空間に存在する既存の例外をスローすることを検討してください。

他の既存の例外とは異なる方法でプログラムで処理できるエラー状態がある場合は、カスタム例外を作成してスローしてください。それ以外の場合は、既存の例外の 1 つをスローします。

チームの例外を作成するためだけに、新しい例外を作成してスローしないでください。

于 2010-02-06T23:32:57.847 に答える
2

問題は、経験を偽造しようとしている経験の浅い候補者を捕まえることだと私には思えます。私の意見では、独自の例外をスローすることは何も悪いことではなく、ここで回答した他のすべての人にわかるように.

于 2010-02-07T01:03:35.440 に答える
2

例外を再スローするのがなぜ悪い考えなのかと疑問に思われるかもしれません。

「再スロー」とは、例外をキャッチし、新しい例外を生成してスローすることを意味します。元のスタック トレースを消費して、エラーのすべてのコンテキストを失う可能性があるため、これは問題になる可能性があります。

于 2010-02-06T23:19:07.613 に答える
2

独自の例外を作成しても問題はありません。これは、状況に適した情報を正確に伝えるように調整できます。Aは、AConfigFileNotFoundExceptionよりも多くの情報を伝えFileNotFoundExceptionます (どのファイルが見つかりませんでしたか?)。

ただし、必ずコードですべてのカスタム例外をキャッチして処理するようにしてください。例外がモジュールの外のどこかに飛んでくると (それをパッケージと呼び、名前空間と呼びます)、そこにいる人々はそれが存在することさえ知りません。を除いて。catch (Throwable t) {/* whut? */}

于 2010-02-07T00:06:05.367 に答える
2

例外タイプに追加したい特別なものがない限り、独自のタイプの例外を発明しないでください。

API のユーザーに無効な引数を提供したことを伝えたい場合は、ArgumentException をスローする必要がありますが、通常の例外では伝達できないライブラリ固有の理由でライブラリが失敗した場合は、ロールする必要があります。開発者が必要とする情報を含めます。

于 2010-02-06T23:27:27.563 に答える
2

Peter の回答を続けると、例外をスローするのが得策ではない別のケースとして、プログラムのビジネス ロジックを制御するために例外のスローを使用する場合があります。

スローする例外が適切なオブジェクトから派生し、例外的な状況を伝える限り、例外のスローは完全に許容されます。

ビジネス ロジックを制御するために例外のスローを使用することは、設計パターンが悪いだけでなく、パフォーマンスにも影響します。例外のスローとキャッチは、メソッドから返された結果に基づく分岐と比較して、かなりコストがかかります。

于 2010-02-06T23:41:50.103 に答える
1

それはまったく悪い考えではありません。例外的な状況が発生した場合は、それを処理するために例外をスローする必要があります。特に、他のユーザーが使用する可能性のあるコードを設計している場合や、不適切な入力を受け取る可能性がある場合などです。

コード内の通常のチェックによって、または通常の実行の一部として回復可能な状況など、絶対に必要ではない例外を使用することはお勧めできません。それが、一般的に悪い考えであるという考えをあなたが得たかもしれないところだと思います。しかし、本来の目的 (コードで処理できない例外的な状況にフラグを立てること) に関しては、絶対に最適なツールです。

また、他のユーザーが使用する可能性のあるコードのカスタム例外を作成する場合は、その内容と意味を文書化してください。そうすれば、後でコードを使用するユーザーは、それらが可能であり、発生した場合に何を意味するかを知り、適切に処理できます。

于 2010-02-06T23:19:44.710 に答える