5

原則として、Exception のインスタンスをスローしないようにしています。なぜなら、これは何が問題なのかについて多くの情報を伝えないからです。

しかし、私はこのように見えるかなりの数の空の例外クラスを取得していることに気づきました...

class DataNotFoundException extends Exception {
   // just a tagging class
}

したがって、機能的にはこのクラスは Exception と同じです。唯一の機能的な意味は、これができるようになったことです...

try {
    ... some code which throws exceptions ...
} catch (DataNotFoundException $dnfe) {
    ... do stuff ...
} catch (OtherException $oe) {
    ... do other stuff ...
}

私の質問は、膨大な数の小さな例外クラスを持つことと、単に例外のインスタンスをスローすることの間のバランスはどこにあるかということです。新しい例外クラスをいつ導入するかについてのガイドラインはありますか?

4

2 に答える 2

2

例外を処理するロジックが異なる場合は、常に Exception クラスを拡張する必要があります。php Spl ライブラリを探してください。いくつかの例外クラスが含まれているため、独自に定義する必要はありません。

于 2012-08-02T16:20:51.473 に答える
1

多くの特定の例外を含めることは悪い習慣ではありませんが、関連性があり再現可能なものだけです。それらを非常に具体的にすることを選択した場合は、それも特定の順序で行う必要があります。非常に具体的なものから一般的なものへと変化します。

try {}    catch (CryptographicException e)
{ ...doSomething }

catch (ArgumentOutOfBoundsException e)
{ ...doSomething }

catch (Exception e)
{ ...doSomething }

これはイベントの処理に起因し、一般的な例外が最初の場合、他のすべてはスキップされます。一般的な例外の前に特定の例外があると、それらからより多くの情報を取得するという考えにも役立ちます。

于 2012-08-02T16:35:31.693 に答える