0

私は学習目的で個人的なMVCフレームワークを開発しようとしています。しかし、私がこの問題で立ち往生するたびに：エラー。

私はそれらを非常にひどく扱っているような気がします。現在、フレームワークとユーザーアプリケーションのコードのすべての行を含むtry {}ブロックでキャッチされる例外システム（すべてが例外に変換され、PHPでトリガーされたエラーも含まれます）があります。

「コントローラーが見つかりません」や「アクションが見つかりません」などのエラーを他のエラーと同じように扱っています。たとえば、「データベースに接続できません」などです。しかし、後者は、かなり一般的な「コントローラーが見つかりません（404）」というよりも、どういうわけか「例外」であるように感じます。

また、現在、フレームワークでMVCが機能する方法をほぼコピーするエラー処理を使用しています。つまり、エラーが発生したときに、特定のアクションをロードし、エラーの種類ごとに特定のビューファイルをロードします。フレームワークのMVC（MVCとは、コントローラーの読み込み、アクションの実行、ユーザーアプリケーションのモデルとビューの読み込みを行うすべてのメカニズムを意味します）を使用していません。MVCでエラーが発生すると、エラーがトリガーされる可能性があるためです。 、MVCでそれを管理しようとします。これにより、同じエラーが再度トリガーされ、MVCが再びロードされ、以下同様に無限ループになります。

フレームワークのすべてのエラーをどのように処理する必要がありますか？現在のベストプラクティスは何ですか？

4

2 に答える 2

2

コントローラIMHOを実行すると、次の2つの例外が発生する可能性があります。

  • 見つかりません：コントローラーまたはメソッドが欠落している場合
  • 許可が拒否されました：ACLがアクセスをブロックしたとき

これを処理するには、次のコードのようなものを使用します。また、複数のキャッチブロックを使用できます。

try
{
    $controller->$command($request, $response);
}
catch(AccessDeniedException $e)
{
    $controller = new ErrorController;
    $controller->accessDenied($request, $response);
}
catch(NotFoundException $e)
{
    $controller = new ErrorController;
    $controller->notFound($request, $response);
}

モデルレイヤーAccessDeniedExceptionからバブルアップすることもできますが、通常は悪い習慣です。例外は、スローされたのと同じレベルの抽象化内で処理する必要があります。重大な例外の場合（オブジェクト自体がそれを処理できない場合）、例外は1つの抽象化境界を通過する可能性があります。また、例外はモデルレイヤーを離れてはならず、代わりにレイヤーにエラー状態を作成し、現在のビューインスタンスで処理する必要があります。

重要なのは、すべてのエラーの魔法のハンドラーではなく、発生した場所の近くでエラーを処理する必要があるということです。

于 2012-06-16T14:34:00.953 に答える
0

try catchで、より適切なメッセージのようなことを行うことができます。例えば：

try
{
    //Your code here
}
catch (Exception $e)
{
    // Clean the output buffer if one exists
    ob_get_level() and ob_clean();

    // Display the exception text
    echo sprintf('%s [ %s ]: %s ~ %s [ %d ]', get_class($e), $e->getCode(), strip_tags($e->getMessage()), $e->getFile(), $e->getLine())."\n";

    // Exit with an error status
    exit(1);
}
于 2012-06-16T13:33:05.250 に答える