2

オブジェクト指向アプリ (MVC フレームワークで作成) を使用していますが、多くの場合、エラー処理手順はアドホックです。エラーがない場合に 0 を返すこともあればtrue、成功した場合に を返すこともあります。一般的に、一貫性はあまりありません。

私のシナリオは、モデルからメソッドを呼び出すコントローラーがあることです。そのメソッドが失敗した場合、エラーを完了できなかった理由について、人間が判読できる理由を返すようにしたいと考えています。このエラーはユーザーに渡されます。たとえば、userDelete() メソッド。ユーザーが削除されたかどうかを知りたいだけです。削除されていない場合は、その理由は?

true私の以前のアプローチは、削除された場合は戻り、それ以外の場合は文字列を返すことでした。これにより、ifステートメントが少しトリッキーになりました。

if ($output = $this->someMethod())

文字列に対して true を返すため、あまり役に立ちません。

代替案に関する私の考慮事項は次のとおりです。

配列を返す

array ('status'=>'error', 'message' => 'You did not specify an existing user')

これは、上記の if ステートメントと互換性があります (つまり、配列が返されると「false」が返されます)。true関数呼び出しが成功した場合に戻ります。

PHP の Exception クラスと try/catch ブロックを使用する

コードがエラーに陥った場合 (つまり、ユーザーが存在するかどうかを確認するためにチェックを実行し、否定的であることが判明した場合)

if ($query->count == 0) {
   throw new Exception("User does not exist");
}

そして、呼び出しページに次のように書きます。

try {
   $this->someMethod();
} catch (Exception $e) {
   echo $e->getMessage() //Or some other way of handling the error
}

この代替案を進める場合、それは PHP の「悪い形式」ですか? 例外は、「高レベル」のアプリケーション エラー処理/ユーザー フィードバックではなく、実際のコーディング エラー (つまり、0 による除算) にのみ使用する必要がありますか?

覚えておいてください: 実行中のある時点でこれらのエラー メッセージをユーザーに送り返す予定です... PHP 自体によってスローされた他の例外がユーザーに返されることを心配する必要がありますか? これを防ぐために Exception クラスを拡張する必要がありますか?

4

1 に答える 1

0

個人的には、必要に応じてそのステータスと他のすべての有用なログ情報を返して保存できるため、配列のアイデアに似たものを使用します。if(someFunct()) が成功した場合 (成功として true を使用した場合) または空でない配列で true になるため、すべてがうまくいけば、一貫性のために空の配列を返すだけです。このようにして、空の配列 (!someFunc()) を成功とみなします。

ただし、このトピックについて非常に優れていることがわかったこの投稿を自由に見てください。

于 2012-05-17T18:31:07.857 に答える