PHP异常处理技巧与结构详解

本文深入解析了PHP异常处理的核心机制与常见陷阱，澄清了try-catch无法捕获Notice/Warning等错误的根本原因，并提供了通过set_error_handler将可恢复错误转为ErrorException的可靠方案；同时厘清了set_exception_handler与register_shutdown_function的分工边界，强调二者协同而非替代的关系；进一步剖析了Exception与RuntimeException等内置异常类的语义差异及其在日志、监控和团队规范中的实际价值；最后警示finally块中资源清理的隐性风险——如异常覆盖、无效操作和return劫持，并给出安全实践建议。全文直击开发者在真实项目中高频踩坑的盲区，兼具原理深度与落地指导性。

PHP 里 try-catch 捕不到 Notice 和 Warning？

默认情况下，try-catch 只捕获 Exception 及其子类（比如 RuntimeException），而 E_NOTICE、E_WARNING 这类错误是 PHP 错误（error），不是异常（exception）。它们不会自动转成异常，所以直接写 try { trigger_error('xxx', E_USER_NOTICE); } catch (Exception $e) { } 是无效的。

解决办法是用 set_error_handler() 把错误转成异常再抛出：

• 必须在 try 块之前注册错误处理器，否则漏掉初始化阶段的错误
• 注意别把 E_ERROR 等致命错误也转异常——它无法被 catch，会导致脚本直接终止
• 推荐只转换 E_USER_*、E_NOTICE、E_WARNING 这几类可恢复错误

示例：

set_error_handler(function($severity, $message, $file, $line) {
    if (!(error_reporting() & $severity)) {
        return;
    }
    throw new ErrorException($message, 0, $severity, $file, $line);
});

try {
    trigger_error('模拟一个 notice', E_USER_NOTICE);
} catch (ErrorException $e) {
    echo '捕获到：' . $e->getMessage();
}

想全局统一处理所有异常和错误，该用 set_exception_handler 还是 register_shutdown_function？

set_exception_handler() 负责兜底未被捕获的 Exception；register_shutdown_function() 则在脚本结束前执行，常用来捕获致命错误（E_ERROR）或检查 error_get_last()。

二者不互斥，但职责不同：

• set_exception_handler() 只对未被 catch 的异常生效，不能捕获错误（error）
• register_shutdown_function() 必须配合 error_get_last() 才能识别是否发生了致命错误，且此时脚本已无法继续执行逻辑
• 如果用了 set_error_handler() 把错误转异常，那 set_exception_handler() 就能一并兜住——前提是没在错误处理器里静默吞掉或 exit

常见误操作：在 register_shutdown_function 里直接 echo 或 var_dump，结果输出被缓冲或响应头已发送，看不到内容。

throw new Exception() 和 throw new RuntimeException() 有什么实际区别？

区别不在语法，而在语义和后续处理逻辑。PHP 内置异常类有继承关系：RuntimeException 是 Exception 的子类，而框架或团队规范往往按类型做差异化处理。

• 用 Exception 表示通用、非特定场景的异常，比如配置读取失败、参数校验不通过
• 用 RuntimeException 明确表示“运行时才暴露的问题”，比如文件不可写、数据库连接超时、扩展模块未启用
• 日志系统或监控工具可能根据异常类名打标，RuntimeException 更容易被识别为需告警的生产问题
• 别为了“看起来高级”乱用子类，比如把表单验证失败 throw 成 LogicException——它本意是代码逻辑矛盾（如 switch 缺少 default），不是业务规则不满足

使用 finally 块释放资源时，要注意哪些隐性陷阱？

finally 确实会在 try 或 catch 之后无条件执行，但它不保证“安全完成”——如果 finally 里又抛异常，会覆盖前面的异常。

• 如果 try 中抛了异常 A，finally 中又抛异常 B，外部只能看到 B，A 被吞掉（PHP 7.4+ 会提示 Uncaught Exception，但调用栈仍丢失 A）
• 涉及资源清理（如 fclose()、mysqli_close()）时，先判断资源是否有效再操作，避免 fclose(null) 触发新警告
• return 在 finally 中会覆盖 try 或 catch 中的返回值，慎用

更稳妥的做法是：在 finally 中只做清理，不抛异常、不 return；真要处理异常，改用 try-catch 包一层。

异常处理最易被忽略的点：错误级别开关和错误处理器的生命周期。比如在 Composer 自动加载器里触发 E_WARNING，但 set_error_handler 还没注册，这个警告就永远消失了——既没进日志，也没被转异常。

今天关于《PHP异常处理技巧与结构详解》的内容就介绍到这里了，是不是学起来一目了然！想要了解更多关于的内容请关注golang学习网公众号！