PHP 错误与异常处理机制：从 set_error_handler 到自定义异常体系

PHP 的错误处理机制在语言发展过程中经历了多次演进。从早期简单的 die() 输出，到 set_error_handler 的自定义拦截，再到面向对象异常体系的全面引入，PHP 逐步构建起一套兼顾灵活性与工程化的错误管理方案。理解这套机制的内在逻辑，对于编写健壮、可维护的 PHP 应用至关重要。

PHP 错误与异常的本质区别

在深入处理机制之前，有必要厘清 PHP 中“错误”与“异常”的差异。

错误（Error） 通常指 PHP 引擎在运行过程中检测到的语法或环境问题，如除零操作、调用未定义函数、访问不存在的文件等。传统上，这类问题通过 trigger_error() 或引擎内部触发，属于“非异常”的错误级别。

异常（Exception） 则是面向对象语境下的可抛出对象，代表程序执行中偏离正常流程的情况。PHP 5 引入 Exception 类，PHP 7 进一步引入 Error 类并将其与 Exception 统一到 Throwable 接口之下，使错误也能以异常形式被捕获。

关键转折在于 PHP 7：Error 和 Exception 都实现了 Throwable，这意味着开发者可以用 catch (Throwable $e) 同时处理两类问题，极大简化了顶层错误捕获逻辑。

set_error_handler：自定义错误拦截

set_error_handler() 允许开发者注册一个回调函数，接管 PHP 传统错误（E_WARNING、E_NOTICE、E_USER_ERROR 等）的处理流程。

set_error_handler(function ($errno, $errstr, $errfile, $errline) {
    // 将错误转换为异常抛出
    throw new ErrorException($errstr, 0, $errno, $errfile, $errline);
});

这段代码展示了最常见的用法：将传统错误统一转换为 ErrorException 异常。这样做的好处是，所有问题都可以通过 try-catch 结构处理，避免错误处理代码散落各处。

但需要注意几个限制：

• set_error_handler 无法处理 E_ERROR、E_PARSE、E_CORE_ERROR 等致命错误，这些错误发生在脚本解析或核心执行阶段，自定义处理器无能为力。
• 回调函数必须返回 true 才能阻止 PHP 内置错误处理器的后续执行。
• 在回调内部再次触发同类错误可能导致递归，需要谨慎设计。

异常体系的核心结构

PHP 的异常体系以 Throwable 为根接口，下分两个分支：

• Exception：用于用户级可恢复的异常情况。
• Error：用于引擎级错误，如 TypeError、DivisionByZeroError、ParseError 等。

Exception 类提供了若干关键方法：

• getMessage()：异常消息
• getCode()：异常代码
• getFile() / getLine()：抛出位置
• getTrace() / getTraceAsString()：调用栈信息
• getPrevious()：前一个异常（用于异常链）

通过继承 Exception，开发者可以定义业务语义明确的异常类型。

构建自定义异常体系

在中小型项目中，直接抛出 Exception 或许足够。但在大型应用中，自定义异常体系能带来显著的可维护性优势。

按业务领域分层

class AppException extends Exception {}
class ValidationException extends AppException {}
class NotFoundException extends AppException {}
class PaymentException extends AppException {}

这种分层方式让捕获逻辑可以按粒度选择：需要处理所有应用异常时捕获 AppException，只需处理验证失败时捕获 ValidationException。

携带上下文信息

自定义异常可以扩展构造函数，携带更多调试信息：

class ValidationException extends AppException
{
    private array $errors;

    public function __construct(array $errors, string $message = 'Validation failed')
    {
        parent::__construct($message);
        $this->errors = $errors;
    }

    public function getErrors(): array
    {
        return $this->errors;
    }
}

这样在捕获时可以直接获取结构化数据，而不是解析字符串消息。

异常链的运用

当底层异常需要转换为上层语义时，使用 $previous 参数保留原始异常：

try {
    $pdo->prepare($sql);
} catch (PDOException $e) {
    throw new DatabaseException('Query failed', 0, $e);
}

这样在日志或调试时，可以沿异常链追溯根本原因。

全局异常处理与错误处理协同

在生产环境中，通常需要设置全局处理器作为最后防线：

set_exception_handler(function (Throwable $e) {
    // 记录日志
    error_log($e->getMessage());
    // 输出友好错误页
    http_response_code(500);
    echo 'Internal Server Error';
});

set_error_handler(function ($errno, $errstr, $errfile, $errline) {
    throw new ErrorException($errstr, 0, $errno, $errfile, $errline);
});

register_shutdown_function(function () {
    $error = error_get_last();
    if ($error && in_array($error['type'], [E_ERROR, E_PARSE, E_CORE_ERROR])) {
        // 处理致命错误
    }
});

这三者配合，覆盖了绝大多数错误场景：set_error_handler 接管可恢复错误，set_exception_handler 处理未捕获异常，register_shutdown_function 兜底致命错误。

实践建议

1. 不要用异常控制正常流程：异常应代表“异常”情况，频繁抛异常会影响性能且降低代码可读性。
2. 异常粒度适中：过细的异常分类会增加维护成本，过粗则失去捕获意义。
3. 始终保留原始异常：转换异常时通过 $previous 传递，避免丢失根因。
4. 生产环境关闭 display_errors：避免敏感信息泄露，改用日志记录。
5. 统一异常入口：在框架入口或中间件中集中处理，避免散落的 try-catch。

PHP 的错误与异常处理机制从早期的简单粗暴，逐步演化为今天层次分明、可扩展的体系。掌握 set_error_handler 的拦截能力，理解 Throwable 的统一结构，并在此基础上构建符合业务语义的自定义异常体系，是每一位 PHP 开发者从“能运行”走向“可维护”的必经之路。

未经允许不得转载：任鹏个人博客 » PHP 错误与异常处理机制：从 set_error_handler 到自定义异常体系