在PHP开发中，错误和异常是两套独立的机制。普通触发warning或notice的函数调用并不会被try-catch捕获，因为异常只能由throw抛出。为了让老代码里大量使用触发错误而非抛异常的函数也能纳入统一异常处理流程，我们需要借助错误处理器和错误抑制符协同工作。
为什么try-catch无法直接捕获PHP错误
PHP在语言层面将错误（error）与异常（exception）区分开。像fopen打开不存在文件、json_decode解析非法字符串，这些内部函数失败时返回false并触发一个E_WARNING或E_NOTICE级别的错误，而不是抛出Exception对象。try-catch结构只能拦截通过throw语句抛出的异常，因此单纯写try-catch包裹这类调用没有任何防护效果。
很多初学者误以为只要把可能出问题的代码放进try块就安全了，结果线上仍然出现未捕获的警告导致部分逻辑中断。理解这一点是写兼容层的前提：我们必须把错误转换成异常，或者主动抑制错误并手动判断返回值。下面这段代码展示了普通try-catch的无效场景。
<?php
try {
$file = fopen('not_exist.txt', 'r');
if ($file === false) {
// 这里只是返回false，不会抛异常，try-catch无感知
echo 'open failed';
}
} catch (Exception $e) {
echo 'never catch warning';
}
?>
用set_error_handler将错误转为异常实现兼容
PHP提供set_error_handler函数，允许我们注册一个回调，在错误发生时优先执行。我们可以在这个回调里根据错误级别决定是否抛出ErrorException，从而把传统错误变成可被try-catch捕获的异常。这种方式适合在应用入口统一注册，让整个项目的错误处理模型一致。
需要注意的是，并非所有错误都能被处理器接管，比如E_ERROR fatal错误无法拦截，但常用的E_WARNING、E_NOTICE都可以。在回调中应当过滤掉不希望转为异常的低级别通知，避免日志被刷屏。以下示例展示了一个兼容异常处理的引导文件写法。
<?php
set_error_handler(function ($errno, $errstr, $errfile, $errline) {
// 只转换警告和提醒，其他交给PHP默认处理
if (!(error_reporting() & $errno)) {
return false;
}
if ($errno === E_WARNING || $errno === E_NOTICE) {
throw new ErrorException($errstr, 0, $errno, $errfile, $errline);
}
return false;
});
try {
$data = json_decode('{bad json}', true);
if ($data === null && json_last_error() !== JSON_ERROR_NONE) {
// 即使json_decode不抛异常，上面的handler也可能已介入
}
} catch (ErrorException $e) {
echo '捕获到错误异常：' . $e->getMessage();
}
?>
这种方案的优点是业务代码完全使用try-catch，风格统一，也方便集中记录错误日志。缺点是如果第三方库内部依赖@抑制符或自身注册了错误处理器，可能产生冲突，因此要在框架启动早期注册，并在CLI模式下谨慎使用。
错误抑制符@与try-catch的混合使用策略
错误抑制符@是PHP特有的单条表达式前缀，作用是临时将该表达式产生的错误报告级别归零。它不会把错误变成异常，只是让页面不输出、不记录。在调用不可控的外部函数（如某些扩展API）时，配合返回值判断再手动throw，是一种轻量兼容写法。
应当避免大面积使用@，因为它在底层会反复切换错误报告状态，有一定性能开销，并且会掩盖真实问题。推荐模式是：用@抑制单点风险，在后面立即用if判断结果，若失败则throw业务异常。这样既屏蔽了噪声，又让上层能用catch统一处理。示例如下：
<?php
function safeInclude($path) {
$result = @include $path;
if ($result === false) {
throw new RuntimeException('加载文件失败：' . $path);
}
return $result;
}
try {
safeInclude('config/local.php');
} catch (RuntimeException $e) {
echo '统一异常出口：' . $e->getMessage();
}
?>
将set_error_handler全局转换与局部@抑制结合，可以覆盖绝大多数遗留代码场景。全局处理器负责把散落的警告收口为异常，@负责在个别嘈杂调用处降噪，两者通过错误级别和代码边界清晰分工，最终让PHP项目在异常层面实现平滑兼容。
实践中的级别控制与日志留存
在生产环境，即便用了兼容异常方案，也不应吞掉所有错误。我们可以在set_error_handler回调里同时写文件日志，再把特定级别转为异常。这样运维侧仍能通过日志发现隐患，而用户侧不会看到黄页。
另一个常见做法是定义业务异常基类，在转换错误时包装为更语义化的子类，例如FileException、NetworkException，让catch块能针对性恢复。下表列出几种错误级别与推荐处理方式：
| 错误级别 | 是否转异常 | 是否用@抑制 | 说明 |
|---|---|---|---|
| E_WARNING | 建议转换 | 可选 | 运行时警告，通常需业务感知 |
| E_NOTICE | 视情况 | 不推荐 | 多为代码疏漏，应修复而非掩盖 |
| E_DEPRECATED | 否 | 否 | 仅提示弃用，记录日志即可 |
通过这种分级策略，团队可以在老项目逐步重构期间，用最小的改动获得统一的异常防护网，等代码全面转向抛出异常后再移除兼容层。
PHP异常处理错误抑制符set_error_handler修改时间：2026-08-15 11:12:29