3

例外をスローするときにオブジェクトをコンストラクターに渡すのは良い考えですか?

サービス パッケージのどこかに次のコードがあるとします。

throw new MyException(object);

MyException クラス:

Object object;
public MyException(Object object) {
    super();
    this.object = object;
}

public Object getObject() {
    return object;
}

そして後で、GUI で、サービスでスローされた例外を処理する必要があるとしましょう。例外をキャッチし、コンストラクターで渡されたオブジェクトにアクセスしたいだけです。これは機能します。しかし、それはスタイルの観点から正しいですか？

getObject() の使用は正しいアプローチですか?

4

4 に答える 4

2

それはあなたが何をしているかに依存すると思いますgetObject。エラーを報告したり、例外からの回復を管理したりするためだけに使用している場合は、これに問題はありません。オブジェクトよりも具体的なものを渡します。たとえば、エラーの原因に関する例外情報を提供し、エラーの解決に役立つ可能性のある有用な情報を取得します。

一方、このオブジェクトを使用して制御フローの通常の分岐を続行する場合、それは例外の通常の使用とは見なされません。繰り返しますが、例外は例外的な状況のためのものであり、それ以上のものではありません。あなたが彼らと何か他のことをしているなら、それは一般的に悪い考えです.

後で処理する結果を取得するために例外を使用している場合、それは設計上の悪臭です。コードをリファクタリングして、これらのオブジェクトを後で処理するためにストアに書き出すことなどを検討してください。例外を悪用しないでください。

于 2012-05-11T08:45:41.217 に答える
0

一般に、はい、例外を処理するコードに役立つ可能性がある例外オブジェクトにデータを追加することは良いことです。

ただし、getObject()を返すメソッドObjectは一般的すぎます。メソッドの名前と、できればオブジェクトの型も例外に固有のものにする必要があります。必要に応じて複数の例外クラスを作成すると、catch ブロックでそれらを区別できます。

最後に、この種のことは通常の制御フローに悪用される可能性があります。これは本質的に「悪」であるという標準的な定説には同意しません。例外は制御フローメカニズムです。しかし、それらはコードの断片を暗黙的に接続するため、保守性が悪いものです。そのため、コール スタックの数レベル上に制御フローを渡す方法が本当に必要であり、代替手段を真剣に検討している場合にのみ使用してください。

于 2012-05-11T08:50:53.597 に答える
0

いつものように、それはあなたのシステム構造とあなたが達成したいことによって異なりますが、IMO はこれが受け入れられる方法です。

実際、これはデフォルトの例外 API がエラー メッセージと原因を処理する方法であり、それらを後で処理するコンストラクター パラメーター (例外コンストラクター API Docを参照) として渡します。

于 2012-05-11T08:51:42.250 に答える
0

例外をキャッチするクラスは、例外にカプセル化されたオブジェクトの (静的) クラスによって異なります。通常、依存関係を最小限に抑えることをお勧めします。そのため、コンポーネントの内部にあるクラスを例外にカプセル化しません。例外とカプセル化されたクラスが同じコンポーネントに属している場合にのみ、コンポーネントのパブリック クラスを例外にカプセル化します。

于 2012-05-11T08:53:37.893 に答える