PHP原理の異常メカニズムを徹底分析

PHP の例外メカニズムの原理は何ですか?

PHP の各独立して実行可能な op 配列の最後にある ZEND_HANDLE_EXCEPTION は何に使用されますか?

質問から始めましょう。先週、blue5tar 「次のコードでは、onError は明らかに実行されますが、onException は実行されません。なぜですか?」という質問がありました。

コードをコピー

function onError($errCode, $errMesg, $errFile, $errLine) {
echo "エラーが発生しました";
throw new Exception($errMesg);

関数 onException($e) {
echo $e->getMessage();

set_error_handler( "onError ");

set_Exception_handler("onException");

/* 私はファイルに自分の名前を付けたことがないので、このファイルは存在しません*/
require(" laruence.php" );


実行結果:

コードをコピー コードは次のとおりです:

エラー発生した

PHP 致命的エラー: main(): Failed open required 'laruence.php


まず、Require に見つからない問題が含まれている場合、前方と後方にスロー 2 つのエラーが発生しました。

コードをコピーします コードは次のとおりです:

1 警告: PHP 時にスローされます。このファイルを開こうとします。

2. E_COMPILE_ERROR: PHP ファイルを開く関数から返された後にスローされます


そして、set_error_handler が E_COMPILE_ERROR エラーをキャッチできないことがわかります:

次のエラー タイプはユーザー定義関数で処理できません: E_ERROR、E_PARSE、E_CORE_ERROR、E_CORE_WARNING、E_COMPILE_ERROR、E_COMPILE_WARNING、および set_error_handler() が呼び出されるファイルで発生する E_STRICT のほとんどは、onError で処理されます。 、最初の WARNING エラーのみをキャッチできますが、onError でスローされた例外はデフォルトの例外ハンドラではキャッチされないのはなぜですか?

これは、PHP の例外メカニズムについてです。

PHP の原理とオペコードを深く理解している人は、PHP5.3 より前では、独立して実行できるすべてのオペ配列 (ファイル、関数、メソッド) の最後のオペコードが ZEND_HANDLE_EXCEPTION であることを知っています。また、このオペコードは何に使用されますか?
PHP では、例外がスローされると、各操作配列の最後の行にジャンプして、この ZEND_HANDLE_EXCEPTION を実行することがわかります。疑似コードは次のとおりです:



コードをコピーします

コードは次のとおりです:

void on_throw_Exception(zval *例外 TSRMLS_DC) { 1. 例外がスローされたかどうかを確認します2 . 例外を記録します

3. 実行される次の op 行のシリアル番号を記録します

4. 実行される次の op 行のシリアル番号 = 現在の op 配列の最後のもの
}


さて、ip レジスタの書き換えと同じように、次に実行する op 行のシーケンス番号を書き換えると、このように ZEND_HANDLE_EXCEPTION の処理ロジックに入ります。 🎜>
ZEND_HANDLE_EXCEPTION では、この例外が try catch にあるかどうかを判断します。

コードをコピーします。

コードは次のとおりです。

そうであれば、次のように記述します。 実行する op 行を最初の catch op 行として設定し、実行を継続します。 そうでない場合は、いくつかの不要な変数と opline を破棄し、直接終了します。実行プロセス

「set_Exception_handler で設定したデフォルトの例外処理関数 (user_Exception_handler) はいつ有効になるのですか?」と尋ねたい学生もいます。

実行が完了し、LOOP が終了した後のデフォルトの例外処理。関数。利用可能な場合にのみ呼び出します。

コードをコピー

コードは次のとおりです。 :

//実行zend_execute( EG(active_op_array) TSRMLS_CC); if (EG(例外)) { if (EG(user_Exception_handler)) {

ユーザー定義のデフォルト例外ハンドラー関数を呼び出します

} else {
キャッチされなかった例外
}
} else {
例外なし
}
destroy_op_array(EG(active_op_array) TSRMLS_CC );
efree(EG(active_op_array));

PHP 例外プロセス
PHP が致命的エラーに遭遇すると、直接 zend_bailout が実行され、zend_bailout によりプログラム フローは上記のコード セグメントを直接スキップします。これは、直接終了 (longjmp) としても理解されます。これにより、user_Exception_handler が機能しなくなります。

これを理解すると、記事の冒頭の問題の理由が明確になると思います。

最後に、 ZEND_HANDLE_EXCEPTION、おそらく学生もいるでしょう。これが事実である場合、なぜすべての独立して実行可能な op 配列の最後にこの ZEND_HANDLE_EXCEPTION があるのでしょうか? 最も単純な場合、関数に throw がない場合、この opcode は明らかに不要です。へー、とても賢いですね、PHP 5.3 からは、あなたのアイデアに従って調整されています。スローの瞬間にのみ、ZEND_HANDLE_EXCEPTION opline が動的に生成されます。

PHP5 変更ログ:

変更。例外処理に、各 op_array には ZEND_HANDLE_EXCEPTION オペコードが含まれなくなりました (Dmitry)。