解读

在 PHP 面试里，这道题考察的是“错误”和“异常”两条并行的处理通道谁先被触发。
国内项目普遍运行在 PHP 7/8 之上，代码里既保留了 set_error_handler 捕获传统错误，又大量使用 try/catch 与 set_exception_handler 做异常兜底。
如果一段代码既触发了 E_WARNING 又抛出了 Exception，到底哪条链路先执行？
理解优先级，才能决定日志顺序、报警策略、以及是否需要在 handler 里做兜底转换（把 Error 转成 Exception），这是高可用后台面试的高频追问点。

知识点

1. PHP 把“错误”与“异常”视为两个独立体系

   • 错误：由 Zend 引擎触发，属于内核事件，默认走 error_reporting → log → display
   • 异常：由用户代码或内置类主动 throw，属于语言级对象，默认走 try/catch → Exception 对象 → 未捕获时 set_exception_handler

2. 触发时机
   同一行代码里，如果既出现“错误”又出现“异常”，内核先完成“错误”阶段的回调，再把控制权交回用户空间；用户空间一旦执行 throw，才进入异常流程。因此：

   • 错误处理器总是先被调用
   • 异常处理器后被调用（仅当异常未被 try/catch 捕获）

3. 返回值决定后续走向

   • 错误处理器返回 true 表示“我已处理”，内核不再继续 error_reporting 默认动作
   • 错误处理器返回 false 或 null，内核继续按原有级别处理，仍可能把 E_ERROR 转成 Fatal，进而触发 shutdown；此时若代码在 shutdown 前又抛异常，异常处理器才介入

4. PHP 7+ 的 Error 类
   TypeError、ParseError 等已继承 Throwable，既可被 try/catch 捕获，也可被 set_exception_handler 捕获；但它们本质仍是“错误”先触发，再包装成对象，因此顺序不变：错误通道 → 异常通道

5. 生产环境常见套路

   • 在错误处理器里把 E_USER_ERROR、E_RECOVERABLE_ERROR 等转为 ErrorException，再 throw 出去，实现“统一异常化”
   • 异常处理器只做最后的日志+报警，返回后进程仍会被终止，需配合 register_shutdown_function 做收尾

答案

错误处理器永远先于异常处理器执行。
内核顺序：触发错误 → 回调 set_error_handler → 若返回 true 则终止错误流程；若返回 false 或脚本继续运行到 throw → 进入 try/catch 或 set_exception_handler。
因此，二者同时生效时，优先级为：
错误处理器 > 异常处理器。

拓展思考

1. 统一异常化方案
   在 Composer 自动加载之后、业务代码之前，先注册一个错误处理器，把所有 E_WARNING、E_NOTICE 记录到 monolog，把 E_USER_ERROR 封装成 ErrorException 并抛出；随后只保留一个异常处理器做兜底，这样全站只有“异常”一条处理路径，日志格式、链路追踪、Sentry 上报都能统一。

2. 与 Swoole/FPM 的差异
   Swoole 的协程内，错误处理器是进程级共享，异常处理器是协程级隔离；高并发服务若依赖全局 handler，必须在 onWorkerStart 重新注册，否则会出现“部分请求无回调”的幽灵问题。

3. 返回值陷阱
   错误处理器返回 true 虽然能屏蔽页面报错，但会让 error_get_last() 为空，导致运维脚本无法抓取最后错误；正确做法是返回 false 并额外写日志，既保留内核信息，又实现自定义格式。

4. 面试追问示例

   • “如果我在错误处理器里又抛了一个异常，后续流程会怎样？”
     答：当前错误处理器被中断，异常立即进入异常处理通道；若异常也未捕获，最终 Fatal error: Uncaught Exception 由 Zend 输出，进程终止。
   • “PHP 8 的 throw 表达式能否改变优先级？”
     答：不能；throw 只是语法位置更灵活，触发时机仍在错误阶段之后。