php - 例外: これは良い習慣ですか?

Question

これは PHP で書かれていますが、実際には言語に依存しません。

try
{
    try
    {
        $issue = new DM_Issue($core->db->escape_string($_GET['issue']));
    }
    catch(DM_Exception $e)
    {
        throw new Error_Page($tpl, ERR_NOT_FOUND, $e->getMessage());
    }
}
catch(Error_Page $e)
{
    die($e);
}

ネストされた try、catch ブロックは従うべき良い習慣ですか? エラーページだけでは少しかさばるように見えますが、エラーが発生した場合、Issue Datamanager は例外をスローし、それがエラー検出の良い方法であると考えています。

Error_Page 例外は、単なるエラーページコンパイラです。

私は衒学的かもしれませんが、これはエラーを報告する良い方法だと思いますか?もしそうなら、これを書くためのより良い方法を提案できますか?

ありがとう

score 9 · Accepted Answer

あなたはページロジックに例外を使用していますが、個人的にはそれは良いことではないと思います。例外は、エラーページの出力を制御するためではなく、悪いことや予期しないことが発生したときに通知するために使用する必要があります。例外に基づいてエラーページを生成する場合は、set_exception_handlerの使用を検討してください。キャッチされなかった例外は、指定したコールバックメソッドを通じて実行されます。これは例外の「致命性」を止めるものではないことに注意してください。コールバックを介して例外が渡された後、例外がキャッチされなかった場合、実行は通常どおり停止します。

score 2 · Accepted Answer

巣立ちはしないほうがいいと思います。複数の例外タイプが予想される場合は、複数のキャッチを用意してください。

try{
  Something();
}
catch( SpecificException se )
{blah();}
catch( AnotherException ae )
{blah();}

score 2 · Accepted Answer

理想は、例外を処理できるレベルで例外をキャッチすることです。前でもなく（時間の無駄）、後でもありません（コンテキストを失います）。

したがって、$tpl と ERR_NOT_FOUND が、新しい DM_Issue 呼び出しの近くでのみ「知られている」情報である場合、たとえば、DM_Issue を作成して ERR_SOMETHING_ELSE が必要な場所が他にある場合、または $tpl の値が異なるため、 ' 適切な場所で最初の例外をキャッチしています。

その場所から死に至る方法は別の問題です。別の方法は、その場で死ぬことです。しかし、それを行うと、エラーの後、終了する前に、介入するコード (何らかの方法で何かをクリアしたり、エラーページを変更したりするなど) を行う機会がなくなります。明示的な制御フローがあることも良いことです。だから私はあなたが良いと思います。

あなたの例は完全なアプリケーションではないと仮定しています-もしそうなら、おそらく不必要に冗長であり、DM_Exception catch 句で死ぬ可能性があります。しかし、実際のアプリについては、何もないところで死なないという原則には賛成です。

score 0 · Accepted Answer

必要に応じてこれで問題ないかもしれませんが、一般的に、例外をキャッチし、メッセージを新しい例外でラップし、再スローするのはかなりためらっています。例外。ラッピング例外を調べるときにその情報が必要ないと確信している場合は、おそらく問題ありません。

score 0 · Accepted Answer

PHPについてはわかりませんが、たとえばC＃では、複数のcatch-Blockを使用できるため、ネストされたtry/catch-combinationsは必要ありません。

一般に、try/catch/finally を使用したエラー処理は常に常識的であり、エラーページを「のみ」表示する場合も同様であると考えています。エラーを処理し、クラッシュ時の奇妙な動作を回避するためのクリーンな方法です。

score 0 · Accepted Answer

例外は、データベースクエリが正しく実行されていない、または何かが正しく構成されていないなど、潜在的なサイト破壊イベントが発生した場合にのみ使用する必要があります。良い例は、キャッシュまたはログディレクトリが Apache プロセスによって書き込み可能でないことです。

ここでの考え方は、開発者であるあなたが、サイト全体を壊す可能性のあるコードを停止して、展開前に修正できるようにするための例外です。また、環境が変更された場合 (つまり、誰かがキャッシュフォルダーのアクセス許可を変更したり、データベーススキームを変更したりした場合) にサイトが何らかの損害を被る前に停止されることを確認するためのサニティチェックでもあります。

いいえ。ネストされた catch ハンドラーはお勧めできません。私のページでは、私の index.php ファイルはそのコードを try...cache ブロックにラップしています。何か問題が発生した場合は、それが本番環境にあるかどうかを確認します。そして、私に電子メールを送って一般的なエラーページを表示するか、画面にエラーを表示します。

注意: PHP は C# ではありません。C# は (ASP.net の例外 (冗談じゃない:p) を除いて) 状態を含むアプリケーション向けですが、PHP はステートレスなスクリプト言語です。

score 0 · Accepted Answer

issue not found で例外をスローすることはありません。これはアプリケーションの有効な状態であり、404 を表示するためだけにスタックトレースは必要ありません。

キャッチする必要があるのは、SQL エラーなどの予期しないエラーです。例外処理が役立つのはそのような場合です。コードを次のように変更します。

try {
    $issue = DM_Issue::fetch($core->db->escape_string($_GET['issue']));
}
catch (SQLException $e) {
    log_error('SQL Error: DM_Issue::fetch()', $e->get_message());
}
catch (Exception $e) {
    log_error('Exception: DM_Issue::fetch()', $e->get_message());
}

if(!$issue) {
    display_error_page($tpl, ERR_NOT_FOUND);
}
else
{
    // ... do stuff with $issue object.
}

php - 例外: これは良い習慣ですか?

7 に答える 7

Related

Reference