2

エラーなどを返すためにメインクラス内に例外を作成する標準が使用されています...問題は、すべての標準スニフがこれを好まないことです。このために独自のスニフを書いていますが、なぜこれが望ましくないのかを尋ねてみようと思いましたか?

たとえば、次のようなものがあります。

<?php
class FOO_EXCEPTION extends Exception   {   }
class FOO_EXCEPTION_BAR extends FOO_EXCEPTION   {   }
class FOO_EXCEPTION_POLE extends FOO_EXCEPTION  {   }

class FOO
{
    public function MethodDoingSomething()
    {
        if('some condition happens')    {
            throw new FOO_EXCEPTION_BAR();
        }

        if('some other condition')  {
            throw new FOO_EXCEPTION_POLE();
        }
        ...
    }
}
?>

これにより、コードは呼び出し元に何が起こったかを示すためにさまざまな例外を返すことができますが、専用の try/catch が利用できない場合でも、基本的な例外がキャッチされる可能性があります。

これは、エラーを処理するためにコール スタックの上位にあるコンポーネントにエラーの性質が返される可能性があるため、データベースやその他の外部オブジェクトを操作する場合に便利です。

たとえば、ファイルを削除しようとしていてファイルが存在しない場合、コードは例外をスローする可能性がありますが、ファイルが存在しないことを気にしない場合、呼び出し元にはこれを無視するオプションがあります。とにかく削除します。ただし、別の呼び出し元は、ファイルが削除されたときに存在すると想定されていたファイルがないとエラーになる可能性があります。

4

1 に答える 1

2

私の意見では、質問で説明したコーディング標準は完全に合理的です。そして、プロジェクトの目的のためには、コードベースを調整して時間を無駄にするよりも、この特定の（特別な）ケースでコードで機能するように、「ファイルごとに標準の複数のクラス」スニフを調整する方がよいと思います」この特定のスニフについては、法律の条文」を参照してください。

一般に、複数のクラス定義を 1 つのファイルに入れることは避けたほうがよいという主張に同意します。しかし、例外から派生したすべてのクラスを独自の個別のファイルに移動するために (これまでに) 読んだすべての引数は、コードを読みにくくすることでコードを「改善」するように勧めているように思えます。人間として、コードを 1 行ずつ含むファイルで雑然とさせても、保守性の利点は得られません。

たとえば、各クラスが独自のファイルに存在する場合、オートローダーを作成する方が簡単であることは事実です。また、何らかのメタ言語から PHP コードを生成/コンパイルしている場合は、ディレクトリ構造に余分なレベルを追加してもコストはかかりません。しかし、私は、コードをこのように編成することで、実際に人間にとって有用な方法でコードが改善されるという結論を拒否します。

編集: 記録のために、実際に「テスト可能な」ロジックが含まれている場合、例外派生クラスの定義を独自のファイルに移動することをお勧めします。このような場合、クラスを使用するロジックの自動テストを作成するときにクラスをモック/スタブする必要がある場合があります。これには、クラス定義を使用するロジックとは別にクラス定義をロードできる必要があります。しかし、これは、例外派生クラスがすべて「空」である元の質問で説明されている状況ではありません。

于 2013-01-07T04:47:40.587 に答える