PHP 优雅的捕获处理错误 -- E_PARSE / E_ERROR

开发中使用的框架，大都可以做到优雅的回显出语法级的错误，即 Parse Error（syntax error）E_PARSE，此错误作为面向用户代码最底层的错误如何进行捕获？

下面主要讲一下如何捕获 E_PARSE & E_ERROR 错误，这里我刻意的把 E_PARSE 错误放前位的，因为 E_PARSE 是面向用户脚本第一位的错误，即若有必然最先发生。而后才是 E_ERROR & E_WARNING & E_NOTICE ....一类的运行时错误。

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

先看一些问题代码

天真的想法

1、想关闭所有的错误报告

<?php
// 不报告任何级别的错误
error_reporting(0);
// 关闭错误回显
ini_set('display_errors', false);

echo 'i lost semicolon operator'

PHP 依然使用自身的错误机制报错，原因很简单：语法解析 -- 解释运行 -- 结束退出。当脚本最基本的语法存在问题时，Zend Engine 自身就会退出执行，并回显 Parse ERROR 错误信息。此时还未解释执行用户代码，即 error_reporting(0) 还没有在 Zend Engine 中对运行时做运行时环境的设定。

2、想使用 set_error_handler 捕捉错误

<?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()。

官方原话讲解：

如果错误发生在脚本执行之前（比如文件上传时），将不会调用自定义的错误处理程序因为它尚未在那时注册。

再说，退一步讲， 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 依然能捕捉到相应的错误。

若干问题

1、为何很多框架都可以优雅的捕获到语法或致命错误（E_PARSE & E_ERROR）呢？比如 laravel 标配的 whoops 
2、E_PARSE & E_ERROR 到底如何才能捕捉到？
3、以上示例貌似都在说 E_PARSE & E_ERROR 这种错误无法捕获，那让用户来自定义告警的
error_reporting() 的级别里为何还有它俩？

既然有相应的级别设置，那就说明是可以被捕捉的，先简单说明一下，E_ERROR 的捕捉其实很简单，E_PARSE 的捕捉则需解释和理解一下，会涉及到 PHP 解析和运行脚本的机制流程。

剖析 PHP 基本的运作机制

其实非常简单，看一遍就理解了（下文中一些运行机制用词可能不准确，还请大佬放过，一切为了让大家能容易理解）。

1、php 在解释运行用户代码时，会以主脚本为载入点，Zend Engine 首先对其进行语法解析（Parse），这里一定要理解，Zend Engine 此时是对脚本的语法进行解析，脚本中的任何 ini 设置都对其无效（还没解释载入执行初始化），所以你设置的什么 error_reporting, display_errors, set_error_handler。只有当语法解析无误，Zend Engine 开始载入并解释脚本，脚本里的一些参数设置项才会开始生效。

2、php 没有 //链接依赖库 -- 编译 -- 运行// 一说。当 php 在主脚本中 “引入依赖” 时，Zend Engine 并不会在对主脚本做语法解析时将其 “依赖” 也载入解析。Zend Engine 只会对当前的主脚本做语法解析，在解析通过后，便开始解释执行用户代码，即便 “依赖” 中有 Parse Error，那也得等到真的执行到载入命令时才会加载解析-解释-运行。

所以，我们首先要构建一个 Parse OK 的容器，初始化 Zend Engine 的一些运行时配置，比如关闭错误报告，这样整个运行时就是关闭了错误报告的上下文，即便后续有 E_PAESE & E_ERROR 也不会回显错误信息了。但我们的目的是要捕捉。

使用 try ... catch 捕获 E_PARSE & 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 初始化好运行时上下文，此后再载入执行的用户代码都将在此上下文中执行，其后的业务逻辑。

合理的代码组织结构

示例：
1、关闭所有的错误报告

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 不会被报告出来。但这并不是我们想要的，我们要捕获才对。

2、捕获系统级错误 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 的设定进行处理。