开发中使用的框架,大均可以作到优雅的回显出语法级的错误,即 Parse Error(syntax error)E_PARSE,此错误做为面向用户代码最底层的错误如何进行捕获?php
下面主要讲一下如何捕获 E_PARSE & E_ERROR 错误,这里我刻意的把 E_PARSE 错误放前位的,由于 E_PARSE 是面向用户脚本第一位的错误,即如有必然最早发生。然后才是 E_ERROR & E_WARNING & E_NOTICE ....一类的运行时错误。laravel
PHP 错误级别浏览器
# 系统级用户代码的一些错误类型 可由 try ... catch ... 捕获 E_PARSE 解析时错误 语法解析错误 少个分号 多个逗号一类的 致命错误 E_ERROR 运行时错误 好比调用了未定义的函数或方法 致命错误 # 可由 set_error_handler 捕获处理 E_WARNING 运行时警告 调用了未定义的变量 E_NOTICE 运行时提醒 E_DEPRECATED 运行时已废弃的函数或方法 # Zend Engine 相关的一些错误 内存错误一类的 应该也能经过 try ... catch ... 捕获 略难测试 E_CORE_ERROR E_CORE_WARNING E_COMPILE_ERROR E_COMPILE_WARNING # 用户级自定义错误 可由 trigger_error 触发 可由 set_error_handler 捕获处理 E_USER_ERROR 用户自定义错误 致命错误 未处理也会致使程序退出 E_USER_WARNING E_USER_NOTICE E_USER_DEPRECATED #编码标准化警告(建议如何修改以向前兼容) E_STRICT 部分 捕获的话 try ... catch ... 部分 set_error_handler E_RECOVERABLE_ERROR
先看一些问题代码服务器
一、想关闭全部的错误报告框架
<?php // 不报告任何级别的错误 error_reporting(0); // 关闭错误回显 ini_set('display_errors', false); echo 'i lost semicolon operator'
PHP 依然使用自身的错误机制报错,缘由很简单:语法解析 -- 解释运行 -- 结束退出。当脚本最基本的语法存在问题时,Zend Engine 自身就会退出执行,并回显 Parse ERROR 错误信息。此时还未解释执行用户代码,即 error_reporting(0) 尚未在 Zend Engine 中对运行时作运行时环境的设定。函数
二、想使用 set_error_handler 捕捉错误oop
<?php // 报告全部级别的错误 error_reporting(E_ALL); // 自定义错误捕捉器 set_error_handler(function ($error_no, $error_str, $error_file, $error_line) { }, E_ALL | E_STRICT); echo 'i lost semicolon operator'
依然得不到理想的结果。测试
首先,这段代码也是在解析阶段就报错了,Parse Error 直接退出了,尚未真的执行 set_error_handler()。ui
官方原话讲解:this
若是错误发生在脚本执行以前(好比文件上传时),将不会调用自定义的错误处理程序由于它还没有在那时注册。
再说,退一步讲, set_error_handler 是用来自定义用户级错误 E_USER_ERROR & E_USER_WARNING & E_USER_NOTICE & E_USER_DEPRECATED 和 部分运行时系统错误 E_WARING & E_NOTICE & E_DEPRECATED 的捕获器,即语法解析错误 E_PARSE (Parse Error) 是没法用其捕获到的。
官方原话讲解:
如下级别的错误不能由用户定义的函数来处理: E_ERROR、 E_PARSE、 E_CORE_ERROR、 E_CORE_WARNING、 E_COMPILE_ERROR、 E_COMPILE_WARNING,和在调用 set_error_handler() 函数所在文件中产生的大多数 E_STRICT。
若是定义的 set_error_handler 的 handler 最后返回了 false,则此错误信息会继续被 PHP 的标准错误处理程序处理:经过 error_reporting 的级别设定,该回显的回显(display_errors),该写入错误日志的写入错误日志(log_errors & error_log)
官方原话讲解:
重要的是要记住 error_types 里指定的错误类型都会绕过 PHP 标准错误处理程序, 除非回调函数返回了 FALSE。
注意,set_error_handler 是有本身的捕获级别的,默认 E_ALL | E_STRICT,不过要出去上文说的那几个级别,且不受 error_reporting() 设定的级别影响,即便你 error_reporting(0),set_error_handler 依然能捕捉到相应的错误。
一、为什么不少框架均可以优雅的捕获到语法或致命错误(E_PARSE & E_ERROR)呢?好比 laravel 标配的 whoops 二、E_PARSE & E_ERROR 到底如何才能捕捉到? 三、以上示例貌似都在说 E_PARSE & E_ERROR 这种错误没法捕获,那让用户来自定义告警的 error_reporting() 的级别里为什么还有它俩?
既然有相应的级别设置,那就说明是能够被捕捉的,先简单说明一下,E_ERROR 的捕捉其实很简单,E_PARSE 的捕捉则需解释和理解一下,会涉及到 PHP 解析和运行脚本的机制流程。
其实很是简单,看一遍就理解了(下文中一些运行机制用词可能不许确,还请大佬放过,一切为了让你们能容易理解)。
一、php 在解释运行用户代码时,会以主脚本为载入点,Zend Engine 首先对其进行语法解析(Parse),这里必定要理解,Zend Engine 此时是对脚本的语法进行解析,脚本中的任何 ini 设置都对其无效(还没解释载入执行初始化),因此你设置的什么 error_reporting, display_errors, set_error_handler。只有当语法解析无误,Zend Engine 开始载入并解释脚本,脚本里的一些参数设置项才会开始生效。
二、php 没有 //连接依赖库 -- 编译 -- 运行// 一说。当 php 在主脚本中 “引入依赖” 时,Zend Engine 并不会在对主脚本作语法解析时将其 “依赖” 也载入解析。Zend Engine 只会对当前的主脚本作语法解析,在解析经过后,便开始解释执行用户代码,即使 “依赖” 中有 Parse Error,那也得等到真的执行到载入命令时才会加载解析-解释-运行。
因此,咱们首先要构建一个 Parse OK 的容器,初始化 Zend Engine 的一些运行时配置,好比关闭错误报告,这样整个运行时就是关闭了错误报告的上下文,即使后续有 E_PAESE & E_ERROR 也不会回显错误信息了。但咱们的目的是要捕捉。
<?php error_reporting(E_ALL); // main script echo "this is main script" . PHP_EOL; // 只有当 main script 语法解析 ok,开始载入解释执行到此处时 // lib.php 才会开始被 Zend Engine 作语法解析/解释运行 require_once __DIR__ . '/lib.php'; echo "hello world!" . PHP_EOL;
解析过程:
1:error_reporting(E_ALL); 语法无误 继续 2:echo "this is main script" . PHP_EOL; 语法无误 继续 3:require_once __DIR__ . '/lib.php'; 此语法无误 继续 (注意:此时并不会去载入并对 lib.php 作语法解析检查) 4:echo "hello world!" . PHP_EOL; 语法无误继续
解析完成,语法经过,开始解释执行
执行过程:
1:error_reporting(E_ALL); 将执行环境的错误告警设为用户定义的级别,运行时用户上下文已开始造成 2:echo "this is main script" . PHP_EOL; 输出个字符串 3:require_once __DIR__ . '/lib.php'; 加载不曾载入过的脚本?开始加载执行 解析 - 解释 的流程 4:echo "hello world!" . PHP_EOL; 要在 lib.php 被 解析 - 解释 完成后才会回到此处继续执行
是否是发现了?在 lib.php 被载入前,main script 的一些运行时的参数设置已经生效,好比这里的 error_reporting(E_ALL),lib.php 解析/解释运行时已是在咱们自定义好错误告警级别的上下文中了,Zend Engine 会根据咱们设定的错误告警级别对 lib.php 进行载入。这时就能够明白 E_PARSE & E_ERROR 错误可被用户设定的含义了吧。
即:你首先要有一个绝对正确的容器,负责将一些必要的用户设定传递给 Zend Engine 初始化好运行时上下文,此后再载入执行的用户代码都将在此上下文中执行,其后的业务逻辑。
示例:
一、关闭全部的错误报告
main.js
<?php // main.js as a ini init container error_reporting(0); echo "this is main script" . PHP_EOL; require_once __DIR__ . "/lib.php"; echo "hello world!" . PHP_EOL;
lib.js
<?php // lib.js as logic echo 'i lost semicolon operator'
那么 lib.php 的任何错误都不会被报告出来,由于 main 运行到载入 lib 时,其已向 Zend Engine 发送了 error_reporting(0); 的指令,因此 lib 中的 Parse Error 不会被报告出来。但这并非咱们想要的,咱们要捕获才对。
二、捕获系统级错误 E_PARSE & E_ERROR
首先咱们要有一个容器,让 Zend Engine 载入并初始化运行时候,开始执行。
而后咱们可使用 try ... catch 捕捉错误,以下:
<?php // main.js as a ini init container error_reporting(E_ALL); try { require_once __DIR__ . '/lib.php'; } catch (\Exception $exception) { var_export($exception); } catch (\Error $error) { // 就是这里了,try catch 捕捉了 Error var_export($error); }
输出结果:
ParseError::__set_state(array( 'message' => 'syntax error, unexpected end of file, expecting \',\' or \';\'', 'string' => '', 'code' => 0, 'file' => '...\lib.php', 'line' => 2, 'trace' => array (), 'previous' => NULL, ))
这样便优雅的拿到了 Parse Error 错误,包装一下输出给用户便可。
Parse Error 能够说是用户级的最高一级错误了,Parse Error 了用户脚本就退出了。
然后咱们才会可能遇到 E_ERROR & E_WARNING & E_NOTICE & E_DEPRECATED 等,以下:
<?php error_reporting(E_ALL); try { // 调用一个不存在的方法 func_not_exists("hello world"); } catch (\Exception $exception) { var_export($exception); } catch (\Error $error) { // 就是这里了,try catch 捕捉了 Error var_export($error); }
运行结果
Error::__set_state(array( 'message' => 'Call to undefined function func_not_exists()', 'string' => '', 'code' => 0, 'file' => '...main.php', 'line' => 47, 'trace' => array(), 'previous' => null, ))
如上,语法没有问题,因此不会有 Parse Error,Zend Engine 开始载入脚本解释执行,由于调用了不存在的方法,E_ERROR 触发后被咱们捕获。
try ... catch 能够捕捉 E_PARSE & E_ERROR
set_error_handler 能够捕捉 E_WARNING & E_NOTICE & E_DEPRECATED & E_USER_*
两者联合起来便可捕捉大部分的用户代码层面的错误
<?php // 设定错误监听的级别 // 但不会影响 set_error_handler 和 try ... catch 的捕获 // set_error_handler 和 try ... catch 是将错误处理交给用户 // 只有当用户没有对错误作处理时 // 错误才会根据 error_reporting / display_errors / log_errors / error_log 进行 php 标准的错误处理流程 error_reporting(E_ALL); // 是否回显错误信息,默认 true // 则会将全部监听到的错误信息回显到标准输出:浏览器或者命令行 // 线上环境强烈建议关闭 错误信息会暴露服务器相关信息 ini_set('display_errors', false); // 开启错误日志 // 线上环境强烈建议开启 记录错误日志 ini_set('log_errors', true); // 错误日志的位置 注意:若是 error_log 的路径有误的话 display_errors 会被强制打开 回显错误到标准输出 ini_set('error_log', __DIR__ . '/error.log'); // 以上为 php 标准错误处理 的设定 // E_WARNING E_NOTICE E_DEPRECATED E_USER_* E_STRICT 捕获 set_error_handler(function ($error_no, $error_str, $error_file, $error_line) { echo "erro_no: " . $error_no . " error_str: " . $error_str . PHP_EOL; //注意 程序并不会在这里退出执行 //注意 若是返回了 false 错误会被 php 标准错误处理流程处理 }, E_ALL | E_STRICT); // E_PARSE & E_ERROR 捕捉 try { // E_WARNING 被 set_error_handler 捕获 echo $variable_not_exists; // E_ERROR 被 try ... catch 捕获 func_not_exists("function not exists!"); // E_PARSE 被 try ... catch 捕获 lib.php 中有语法错误 require_once __DIR__ . '/lib.php'; } catch (\Exception $exception) { echo var_export($exception, true) . PHP_EOL; } catch (\Error $error) { echo var_export($error, true) . PHP_EOL; } echo "run finished" . PHP_EOL;
注意 set_error_handler 和 try ... catch 对错误捕获后程序会继续执行下去,并不会当即退出。
E_ERROR & E_PARSE 使用 try ... catch 捕获
E_WARNING & E_NOTICE & E_DEPRECATED & E_USER_* 使用 set_error_handler 捕捉
若没有作相应的处理,则错误信息会提交至 PHP 标准错误处理流程,根据 error_reporting / display_errors / log_errors / error_log 的设定进行处理。