PHP が Yii フレームワークでエラーと例外をどのように処理するかを説明する例

Yii はデフォルトで CApplication に例外とエラーの引き継ぎを実装しています。これは php の set_Exception_handler と set_error_handler を通じて実装されます。これら 2 つの PHP 組み込み関数により、プログラム内で捕捉されなかった例外やエラーを引き継ぐことができ、プログラムの保守性が向上します。

デフォルトでは、Yii は例外処理を CApplication::handleException に割り当て、エラー処理を CApplication::handleError に割り当てますが、エントリ ファイルで 2 つの定数である YII_ENABLE_EXCEPTION_HANDLER を定義できます。 YII_ENABLE_ERROR_HANDLER は、Yii の例外およびエラー引き継ぎメカニズムの使用を禁止するために false です。

以下のコンテンツでは、例外とエラーを総称してエラーと呼び、必要に応じて詳細に区別します。 YII_DEBUG 定数 (デフォルトは false、エントリ ファイルで設定可能) は、エラー情報の表示に非常に重要な影響を与えます。デバッグ モードでは、エラー出力が最も詳細に表示されます。プログラムが動作を開始したら、YII_DEBUG を false に変更する必要があります。

デバッグモードかどうかに関係なく、Yii プログラムがエラーを生成すると、関連するエラー情報が記録されます (エラーレベルはエラー、デフォルトのカテゴリはアプリケーションです)。違いは、デバッグ モードでは、詳細情報が Web ページに直接表示されることです。

CApplication:: handleError($code,$message,$file,$line)

上記のメソッドは、関連するロジックを実装します。特に、restore_error_handler 関数と復元_例外ハンドラー関数には注意してください。これら 2 つの関数が呼び出されないと、後続のエラー処理プロセス中に例外またはエラーが再び発生したときに、CApplication:: handleError が再度呼び出され、無限ループが発生する可能性があります。したがって、Yii は、(PHP のデフォルトのエラー処理メカニズムを使用して) 後続のエラーと例外を引き継ぐための CApplication::handleError の使用を一時的に禁止し、ループ呼び出しが発生しないようにします。

PHP エラー処理 エラーが発生した場合、PHP はどのような情報をログに記録しますか?エラー コード (つまり、PHP の E_ERROR E_WARNING E_STRICT E_DEPRECATED) メッセージの内容 (Unknown vaiable $input など) エラーを生成したファイル パス エラーを生成した行番号 追加の追跡バックトレース情報 (これは debug_backtrace によって取得されます) 現在の URL

対応するログの記録に加えて、Yii はその後のエラー処理 (操作の中断、エラーページの表示など) も実行します。デフォルトでは、エラー処理は CErrorHandler コンポーネントに引き渡されます (ただし、 onError イベントを CApplicaton にバインドすることで処理できます。デバイスはエラー処理の二次的な引き継ぎを実装しており、ここでの設計は非常に柔軟です!)。

この時点で、CErrorEvent ($code、$message、$file、$line などのいくつかの重要なパラメーターを含む) が生成され、処理のために CErrorHandler コンポーネントに渡されます。具体的には、CErrorHandler::handleError によって処理されます。このプロセスは主に、エラー関連の情報を整理し、適切な方法で表示するために行われます。

デバッグ モード (YII_DEBUG==true) かどうかは、エラー メッセージの表示に大きな影響を与えます。デバッグ モードでは詳細なエラー追跡情報を表示する必要があり、実稼働モードではユーザー フレンドリーなページを表示する必要があります。そのため、ここでのエラー表示が異なりますので、その違いを以下に説明します。

デバッグ モードでは、例外ビューが直接レンダリングされてエラーが表示されます。次のパスに従って検索されます:

protected/views/system/Exception.php

YII_PATH/views/Exception.php

明らかに、これはアプリケーションのデフォルトでは、views/system ディレクトリが定義されているため、システム フレームワークに付属のビュー ファイルが使用されます。最後にインクルードされるファイルは、Yii フレームワークの views/Exception.php になります。

上記の分析から、デバッグ モードでカスタム例外ページを使用したい場合 (通常はあまり意味がありません)、ファイル protected/views/system/Exception を構成する必要があることがわかります。 .php 、使用できる変数は $data です。

非デバッグ モードの場合、次の処理が実行されます。

設定ファイル内の errorHandler コンポーネントに errorAction ルーティング情報が定義されている場合は、それを直接実行します。それ以外の場合は、手順 2 を実行します。 。

#エラー ビューをロードしてみます。次のパスに従って検索します (最初に検索されたファイルが使用されます)

protected/views/system/zh_cn/error500.php

protected/views/system/error500.php

protected/views/system/zh_cn/error.php

protected/views/system/error.php

YII_PATH/ビュー /zh_cn/error500.php

YII_PATH/views/error500.php

YII_PATH/views/zh_cn/error.php

Y II_PATH/views/error.php

例外処理 前述の分析によると、例外処理メカニズムはエラー処理メカニズムと似ています。ログも記録されます。レベルはエラーで、分類は "例外.$EXCEPTIONCLASS" です。 CHttpException クラスの例外、分類名は例外です。.CHttpException.$STATUS_CODE。たとえば、データの例外分類は、Exception.CDbException と呼ばれます。

次に、エラー イベント CExceptionEvent が errorHandler に渡されて処理され、すべてのエラー情報が CExceptionEvent オブジェクトによって渡されます。処理方法は以下の通りです。

デバッグモードの場合、ビューファイルは以下の順番で検索され、最初に検索されたファイルが使用されます

protected/views/system/Exception .php

YII_PATH/views/例外.php

非デバッグ モードで、構成ファイル内の errorHandler コンポーネントに errorAction 属性ルートが定義されている場合は、それを実行します。それ以外の場合は、手順 3 に進みます。

次の順序でビュー ファイルをロードしてみてください。最初に検索されたファイルが使用されます。

protected/views/system/zh_cn/error500.phpprotected/views/system/error500.phpprotected/views/system/zh_cn/error.phpprotected/views/system/error.phpYII_PATH/views/zh_cn/error500.phpYII_PATH/views/error500.phpYII_PATH/views/zh_cn/error.phpY II_PATH/views/error.php

フローチャートの説明を使用すると、より明確になります。ビュー ファイルの検索プロセスは、さらに詳細です。エラー ページのカスタマイズ方法の詳細については、後続のフローチャートでプロセスを詳しく説明します。

図からわかるように、最も簡単な方法は、errorAction 属性を errorHandler コンポーネントに設定して、エラーが発生するルートを指定することです。

一般的に、私たちが最も懸念しているのは、運用モードでのエラー ページの表示です。上記の分析後、利用可能な方法は 2 つあります:

errorAction ルーティング属性を定義する構成ファイル内の errorHandler コンポーネント用 (優先される必要があります。柔軟な構成を実現するには、この方法を使用してください)

次のファイルのいずれかを定義して、カスタム エラー ページを実装します (推奨されません)

保護/views/system/zh_cn/error500.php

protected/views/system/error500.php

protected/views/system/zh_cn/error.php

protected/ views/system/error.php

最初の方法は柔軟で制御可能であり、コントローラーでビュー ファイルを指定できます。

エラー ハンドラーの使用例

yii\web\ErrorHandler は、errorHandler という名前のアプリケーション コンポーネントとして登録されます。これは、アプリケーション構成で次のように構成できます。上記のコードと同様に、例外ページには最大 20 個のソース コードが表示されます。

前に述べたように、エラー ハンドラーは、致命的ではないすべての PHP エラーを取得可能な例外に変換します。つまり、次のコードを使用して PHP エラーを処理できます。エラー ページは、要求が無効であるか、yii\web\NotFoundHttpException などの yii\web\HttpException をスローするだけでは処理できないことをユーザーに伝えます。エラー ハンドラーは、応答 HTTP ステータス コードを正しく設定し、適切なエラー ビュー ページを使用してエラー メッセージを表示します。

return [
'components' => [
'errorHandler' => [
'maxSourceLines' => 20,
],
],
];

カスタマイズされたエラー表示

yii\web\ErrorHandler エラー ハンドラーは、定数 YII_DEBUG の値に従ってエラー表示を調整します。YII_DEBUG が true の場合 (デバッグ モードであることを示します) , エラー ハンドラーは、デバッグに役立つ例外と詳細な関数呼び出しスタックとソース コード行を表示します。YII_DEBUG が false の場合、アプリケーションの機密情報の漏洩を防ぐために、エラー情報のみが表示されます。

補足: yii\base\UserExceptionを継承した例外の場合、YII_DEBUGの値がどのようなものであっても、この種のエラーはエラーとみなされ、関数コールスタック情報は表示されません。ユーザーが生成したエラーであり、開発者は修正することができません。

yii\web\ErrorHandler エラー ハンドラーは、デフォルトで 2 つのビューを使用してエラーを表示します:

@yii/views/errorHandler/error.php: 関数呼び出しスタックを含まないエラー メッセージYII_DEBUG が false の場合に使用され、このビューはすべてのエラーに使用されます。

@yii/views/errorHandler/Exception.php: 関数呼び出しスタック情報を含むエラー メッセージを表示する場合に使用されます。

エラー ハンドラーの yii\web\ErrorHandler::errorView プロパティと yii\web\ErrorHandler::ExceptionView プロパティを設定して、カスタム エラー表示ビューを使用できます。

エラー アクションを使用する

エラー表示をカスタマイズするには、指定したエラー アクションを使用する方が便利です。これを行うには、まず errorHandler の yii\web\ErrorHandler::errorAction 属性を設定します。

use Yii;
use yii\base\ErrorException;
try {
10/0;
} catch (ErrorException $e) {
Yii::warning("pision by zero.");
}
// execution continues...

yii\web\ErrorHandler::errorAction 属性は、アクションへのルーティングに使用されます。上記の構成は、関数呼び出しスタック情報を表示する必要のないエラーが表示されることを示していますサイト/エラー操作を実行することによって。

サイト/エラー オペレーションは次のように作成できます:

use yii\web\NotFoundHttpException;
throw new NotFoundHttpException();

上記のコードは、yii\web\ErrorAction クラスを使用してエラー オペレーションを定義し、エラーを表示するために error という名前のビューをレンダリングします。

yii\web\ErrorAction の使用に加えて、次のような操作メソッドを使用してエラー操作を定義できます。

return [
'components' => [
'errorHandler' => [
'errorAction' => 'site/error',
],
]
];

これで、ビュー ファイルが views/site/ として作成されるはずです。このビューの error.php ファイル内で、エラー アクションが yii\web\ErrorAction として定義されている場合、操作で定義されている次の変数にアクセスできます:

#name: エラー名

message: エラー メッセージ

例外: HTTP ステータス コード、エラー コード、エラー コール スタックなどの詳細情報を含む例外オブジェクト。

補足: Basic Application Template または Advanced Application Template を使用する場合、エラー操作とエラー ビューはすでに定義されています。

カスタム エラー形式

エラー ハンドラーは、応答によって設定された形式に従ってエラーを表示します。yii\web\Response::format 応答形式が html の場合、エラーまたは例外ビューは前のセクションで説明したように、エラー メッセージを表示するために使用されます。他の応答形式の場合、エラー ハンドラーはエラー情報を配列として yii\web\Response::data 属性に割り当て、それを対応する形式に変換します。たとえば、応答形式が json の場合、次の応答情報:

namespace app\controllers;
use Yii;
use yii\web\Controller;
class SiteController extends Controller
{
public function actions()
{
return [
'error' => [
'class' => 'yii\web\ErrorAction',
],
];
}
}

アプリケーション構成の応答コンポーネントの beforeSend イベントに応答することで、エラー応答形式をカスタマイズできます。

return [
// ...
'components' => [
'response' => [
'class' => 'yii\web\Response',
'on beforeSend' => function ($event) {
$response = $event->sender;
if ($response->data !== null) {
$response->data = [
'success' => $response->isSuccessful,
'data' => $response->data,
];
$response->statusCode = 200;
}
},
],
],
];

上述代码会重新格式化错误响应，类似如下：

HTTP/1.1 200 OK
Date: Sun, 02 Mar 2014 05:31:43 GMT
Server: Apache/2.2.26 (Unix) DAV/2 PHP/5.4.20 mod_ssl/2.2.26 OpenSSL/0.9.8y
Transfer-Encoding: chunked
Content-Type: application/json; charset=UTF-8
{
"success": false,
"data": {
"name": "Not Found Exception",
"message": "The requested resource was not found.",
"code": 0,
"status": 404
}
}

推荐学习：php视频教程

以上がPHP が Yii フレームワークでエラーと例外をどのように処理するかを説明する例の詳細内容です。詳細については、PHP 中国語 Web サイトの他の関連記事を参照してください。