PHP error把可捕获错误统一转成异常的实现方法

PHP 项目里最容易失控的不是异常本身，而是 warning、notice 和旧代码里的 trigger_error() 走了另一套日志路径。需要统一处理时，可以用 set_error_handler() 接管指定错误级别，再把回调参数封装成 ErrorException 抛出。这样业务层继续使用 try/catch，日志里也能保留错误级别、文件和行号。

先把错误入口设计成一个窄接口

set_error_handler() 接受一个回调和可选的错误级别掩码。回调返回后，脚本会继续执行下一条语句；因此“记录后继续”与“转换后中断”必须在接口设计里分开。对迁移中的项目，建议先只接管 E_WARNING | E_USER_WARNING | E_NOTICE | E_USER_NOTICE | E_DEPRECATED | E_USER_DEPRECATED，不要一上来扩大范围。

下面的回调只做一件事：把可捕获错误转换为异常。error_reporting() 的当前值用于判断调用方是否暂时屏蔽了该错误；不在当前报告范围内时返回 false，让原有处理器继续接手。

getSeverity(),
        $exception->getMessage(),
        $exception->getFile(),
        $exception->getLine()
    ));
} finally {
    // 临时接管结束后恢复上一个用户处理器。
    restore_error_handler();
}
?>

让异常对象承载原始错误上下文

ErrorException 的 severity 可以保存原始错误级别，getFile() 和 getLine() 则保留发生位置。不要在回调中只拼接一段字符串，否则后续日志系统无法按级别聚合，也不能可靠地区分业务触发的 E_USER_WARNING 和 PHP 自身的 E_WARNING。

对于需要兼容旧处理器的模块，回调也可以返回 false。PHP 手册明确说明：返回 false 时，正常错误处理器会继续执行；返回后脚本默认继续，只有回调主动抛出异常或调用 exit() 才会改变控制流。

把可捕获级别与不可捕获级别分开配置

常见误区是把 E_ALL 当作“所有错误都能转异常”。它只是掩码，不能突破 PHP 对 E_ERROR、解析错误和核心错误的处理边界。生产环境还应关闭直接输出，把异常统一写入应用日志；开发环境则保留足够的文件与行号信息。

相关问题

set_error_handler 能捕获 PHP 解析错误吗？

不能。E_PARSE、E_ERROR、E_CORE_ERROR 等错误不在用户定义处理器的覆盖范围内，应该通过部署前语法检查、运行环境日志和代码修复处理。

为什么回调里要判断 error_reporting()？

因为处理器被调用时，仍可能遇到调用方通过 @ 或报告级别暂时屏蔽的错误。判断当前报告值并返回 false，可以避免把原本被屏蔽的错误强行升级成异常。

如何撤销临时错误处理器？

调用 restore_error_handler()。不要把 set_error_handler() 的返回值再次传给 set_error_handler()，那会继续向处理器栈压入一层。

统一错误入口的关键不是“全部转异常”，而是明确哪些级别由当前模块负责、哪些级别继续沿用默认链路。先收窄掩码，再保留原始上下文，最后在模块边界恢复处理器，迁移过程会更可控。