4

私は、多くの（最大100の）異なるエラーコードを返すことができるいくつかのAPIへのPHPインターフェースに取り組んでいます。私のインターフェースは、そのようなコードが検出されたときに例外をスローすることになっています。私のPHPは少し錆びているので、現在のphpプログラマーに最適なオプションは何かわかりません。

  • MyApiThisAndThatErrorエラーコードごとに個別のクラスがありますか？
  • または、ジェネリッククラスがMyApiErrorあり、引数としてAPIエラーコードを提供しますか？

私はまた、代替案を受け入れています。

4

3 に答える 3

7

TLDR： APIエラーコードを含む汎用のMyApiExceptionクラスを使用します。

Ralph Schindlerは、一般的なトピックに関するすばらしい記事をhttp://ralphschindler.com/2010/09/15/exception-best-practices-in-php-5-3に書き込みました。

すべてを読むと、次のようなセクション「ライブラリコードのベストプラクティス」が表示されます（このコンテキスト用に彼の例を変更しました）。

// usage of bracket syntax for brevity
namespace MyCompany\Component {

    interface Exception
    {}

    class MyApiException 
        extends \RuntimeException 
        implements Exception
    {}

    class Component
    {
        public static function doSomething()
        {
            $myApiCall->doSomthing();
            if ($myApiCall->hasError) {
                throw new MyApiException($myApiCall->getMessage(), $myApiCall->getErrorCode);
            }
        }
    }
}

上記のコードを想定すると、MyCompany \ Component \ Component :: doSomething（）を実行すると、doSomething（）メソッドから発行される例外は、次のいずれかのタイプでキャッチできます：PHPの例外、SPLのRuntimeExceptionコンポーネントのMyCompany \ Component \ MyApiException、またはコンポーネントのMyCompany \ Component\Exception。これにより、呼び出し元は、ライブラリ内の特定のコンポーネントから発生する例外をキャッチする機会がいくつも与えられます。これは、返されたAPIエラーによって引き起こされます。さらに、例外を構成するタイプを分析することにより、発生したばかりの例外的な状況により多くの意味を与えることができます。

于 2013-03-27T17:47:30.163 に答える
3

同様の問題がありました。それを行ったとき、すべてのエラーをファミリー（つまり、クエリ、モデル、コントローラー、フォームなど）に分割し、各エラーファミリー内で、各エラーコードの定数を定義しました。

理想的には、統一された例外クラスが必要でしたが、try catchブロック内に一連の関数呼び出しがある特定のポイントで、それらを異なるファミリに分割して、キャッチを実行できるようにする方がよい場合があります。各エラーファミリは、次に何をすべきかを適切に決定します。はい、統合されたエラーキャッチャーと、エラー番号からファミリを判別する関数を使用することもできましたが、それほどエレガントではないように見えました。

于 2013-03-27T13:48:34.053 に答える
3

それはいくつかの要因に依存します。私の意見では、これらは特定の例外の理由です：

  1. エラーを論理的にグループ化し、例外に論理的に名前を付けることができます。
  2. エラーには、エラーの種類に応じた追加のデータがあります（この追加のデータを保存でき、ユーザーはset / getを使用してそれらにうまくアクセスできます）。
  3. 新しいエラータイプが追加されることはめったにありません（ただし、不明なエラーコードに対してはいつでも基本的な一般的な例外をスローできます）。
  4. エラーの意味は時間とともに変化します（インターフェイスのユーザーは、基になるエラーコードではなく、例外タイプに基づきます）。
  5. ユーザーが根本的なエラーコードに基づいてAPIドキュメントを検索する必要がないように、特定の例外を適切にドキュメント化する準備ができています。
于 2013-03-27T14:22:34.407 に答える