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

依然得不到理想的结果。
首先，这段代码也是在解析阶段就报错了，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

解析过程：
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

lib.js

那么 lib.php 的任何错误都不会被报告出来，因为 main 运行到载入 lib 时，其已向 Zend Engine 发送了 error_reporting(0); 的指令，所以 lib 中的 Parse Error 不会被报告出来。但这并不是我们想要的，我们要捕获才对。
2、捕获系统级错误 E_PARSE & E_ERROR
首先我们要有一个容器，让 Zend Engine 载入并初始化运行时候，开始执行。
然后我们可以使用 try ... catch 捕捉错误，如下：

输出结果：
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 等，如下：

运行结果
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_*
二者联合起来即可捕捉大部分的用户代码层面的错误

注意 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 的设定进行处理。