PHP自定义错误处理方法解析

<?php
// 假设这是你的错误日志文件路径
define('ERROR_LOG_FILE', __DIR__ . '/application_errors.log');

function myCustomErrorHandler($errno, $errstr, $errfile, $errline) {
    // 根据错误类型决定如何处理
    switch ($errno) {
        case E_USER_ERROR:
        case E_RECOVERABLE_ERROR:
            $type = 'Fatal Error';
            $level = 'ERROR';
            break;
        case E_WARNING:
        case E_USER_WARNING:
            $type = 'Warning';
            $level = 'WARN';
            break;
        case E_NOTICE:
        case E_USER_NOTICE:
            $type = 'Notice';
            $level = 'INFO';
            break;
        default:
            $type = 'Unknown Error';
            $level = 'DEBUG'; // 或者其他默认级别
            break;
    }

    $error_message = sprintf(
        "[%s] %s: %s in %s on line %d\n",
        date('Y-m-d H:i:s'),
        $type,
        $errstr,
        $errfile,
        $errline
    );

    // 写入日志
    error_log($error_message, 3, ERROR_LOG_FILE);

    // 在开发环境中可以显示错误，生产环境则不显示
    if (ini_get('display_errors')) {
        echo "<div style='border: 1px solid red; padding: 10px; margin: 10px;'>";
        echo "<strong>{$type}:</strong> {$errstr} <br>";
        echo "<strong>File:</strong> {$errfile} <br>";
        echo "<strong>Line:</strong> {$errline}";
        echo "</div>";
    } else {
        // 生产环境可以重定向到通用错误页面或显示友好信息
        // header('Location: /error_page.html');
        // exit();
    }

    // 如果函数返回 false，则标准的PHP错误处理器还会被调用
    // 返回 true 则阻止标准错误处理器
    return true;
}

// 注册自定义错误处理器
set_error_handler("myCustomErrorHandler");

// 对于未捕获的异常，我们可以这样设置：
function myCustomExceptionHandler(Throwable $exception) {
    $error_message = sprintf(
        "[%s] Uncaught Exception: %s in %s on line %d\nStack trace:\n%s\n",
        date('Y-m-d H:i:s'),
        $exception->getMessage(),
        $exception->getFile(),
        $exception->getLine(),
        $exception->getTraceAsString()
    );

    error_log($error_message, 3, ERROR_LOG_FILE);

    if (ini_get('display_errors')) {
        echo "<div style='border: 1px solid purple; padding: 10px; margin: 10px;'>";
        echo "<strong>Uncaught Exception:</strong> " . $exception->getMessage() . "<br>";
        echo "<strong>File:</strong> " . $exception->getFile() . "<br>";
        echo "<strong>Line:</strong> " . $exception->getLine() . "<br>";
        echo "<pre>" . $exception->getTraceAsString() . "

为什么PHP默认的错误报告机制无法满足现代应用的需求？

PHP默认的错误报告，特别是开发环境下的display_errors = On，虽然直观，但对于一个严肃的、面向用户的应用来说，它简直是灾难。它会把所有错误细节，包括文件路径、行号甚至部分代码逻辑，直接倾泻到用户的浏览器上。这不仅丑陋，极大地损害了用户体验，更是一个严重的安全漏洞，攻击者可以从中获取宝贵的系统信息。

我的经验是，默认机制缺乏灵活性和控制力。我们无法决定哪些错误需要记录，哪些需要立即通知管理员，哪些可以忽略。更别提它无法将错误信息与业务上下文关联起来，比如哪个用户触发了错误，哪个请求参数导致了问题。这使得错误排查变得像大海捞针，效率低下。我们需要的，是一个能够将错误“驯服”的机制，让它们成为我们改进系统的养料，而不是让它们失控地破坏用户体验。

PHP自定义错误处理器与异常处理器，它们在使用场景和最佳实践上有何不同？

自定义错误处理器（通过set_error_handler）和异常处理器（通过set_exception_handler）虽然都旨在处理程序运行时的问题，但它们针对的“问题”类型和设计哲学有着本质的区别。

错误处理器主要应对的是PHP运行时产生的各种“非致命”问题，比如E_WARNING（警告）、E_NOTICE（通知）以及一些用户自定义的E_USER_ERROR等。这些错误通常不会直接导致脚本终止，但可能指示了潜在的问题或不当的操作。我们注册的错误处理器会“接管”这些错误，阻止PHP默认的错误处理行为（比如直接输出到屏幕）。在回调函数中，我们可以选择记录日志、向用户显示友好提示，甚至尝试修复或忽略某些不重要的警告。一个常见的最佳实践是，将这些非致命的PHP错误“升级”为异常，这样我们就可以用统一的异常处理流程来管理所有程序问题。这可以通过在错误处理器中抛出一个ErrorException来实现。

// 在 myCustomErrorHandler 内部
// 将错误转换为异常
if ($errno & error_reporting()) { // 检查当前错误是否在 error_reporting 级别内
    throw new ErrorException($errstr, 0, $errno, $errfile, $errline);
}
return true; // 返回 true 阻止PHP默认错误处理

异常处理器则专注于处理那些通过throw new Exception()或throw new Throwable()抛出的“异常”情况。异常代表了程序流程中的非预期事件，这些事件通常是可预见的，但又无法在当前代码块中立即处理。例如，数据库连接失败、文件不存在、用户输入验证失败等。当一个异常被抛出但没有被任何try...catch块捕获时，它就会被我们注册的异常处理器接管。这里的最佳实践是，异常处理器应该是一个“最终防线”，它负责记录异常的完整堆栈信息，通知开发者，并向用户展示一个友好的、不暴露内部细节的错误页面。它通常会终止当前请求的执行，以避免程序在不确定状态下继续运行。

简而言之，错误处理器是对PHP“抱怨”的统一管理，而异常处理器是对我们自己代码中“问题”的统一善后。将错误转换为异常，可以让我们用一套更加结构化和面向对象的方式来处理所有的运行时问题，这在大型应用中尤为重要。

如何确保自定义处理器能够捕获所有类型的错误，包括那些看似无法捕获的致命错误？

捕获所有类型的错误，尤其是PHP的致命错误（如E_ERROR、E_PARSE、E_COMPILE_ERROR等），是构建鲁棒性错误处理系统的一个关键挑战。因为set_error_handler()只能捕获那些PHP引擎认为可以恢复的错误（例如E_WARNING、E_NOTICE，以及用户自定义错误），而对于那些会导致脚本立即终止的致命错误，它就无能为力了。

解决这个问题的关键在于register_shutdown_function()。这个函数允许我们注册一个回调函数，无论脚本是正常执行完毕，还是因为致命错误而中断，它都会在PHP脚本执行结束时被调用。

在register_shutdown_function的回调函数中，我们可以使用error_get_last()函数来获取脚本终止前发生的最后一个错误信息。如果这个错误是一个致命错误，那么我们就可以在这里进行捕获、记录和处理。

// 再次强调，这是在你的应用初始化阶段就应该注册的
register_shutdown_function(function() {
    $last_error = error_get_last();

    // 检查是否存在错误，并且错误类型是致命的
    if ($last_error && in_array($last_error['type'], [E_ERROR, E_PARSE, E_COMPILE_ERROR, E_CORE_ERROR, E_RECOVERABLE_ERROR])) {
        // E_RECOVERABLE_ERROR 理论上会被 set_error_handler 捕获，
        // 但如果其导致脚本终止，也会在这里被检测到，需要注意去重

        $error_message = sprintf(
            "[%s] Fatal Error (Shutdown): %s in %s on line %d\n",
            date('Y-m-d H:i:s'),
            $last_error['message'],
            $last_error['file'],
            $last_error['line']
        );

        // 写入日志
        error_log($error_message, 3, ERROR_LOG_FILE);

        // 生产环境不显示错误详情，只显示友好提示或重定向
        if (!ini_get('display_errors')) {
            // 避免在已经发送了HTTP头的情况下再次发送，可能需要检查 headers_sent()
            if (!headers_sent()) {
                // 可以重定向到静态的“系统维护中”或“发生错误”页面
                // header('Location: /500.html');
            }
            // 或者直接输出一个简单的友好信息
            echo "An unexpected system error occurred. We are working to fix it.";
        } else {
            // 开发环境可以显示错误
            echo "<div style='border: 1px solid black; background-color: #fdd; padding: 10px; margin: 10px;'>";
            echo "<strong>FATAL ERROR (SHUTDOWN):</strong> " . $last_error['message'] . "<br>";
            echo "<strong>File:</strong> " . $last_error['file'] . "<br>";
            echo "<strong>Line:</strong> " . $last_error['line'];
            echo "</div>";
        }
        // 确保脚本以错误状态码退出
        exit(1);
    }
});

通过这种三管齐下的策略——set_error_handler()处理可恢复错误（并可选地转换为异常）、set_exception_handler()处理未捕获异常，以及register_shutdown_function()捕获致命错误——我们就能构建一个几乎能覆盖所有PHP运行时问题的健壮错误与异常处理系统。这确保了无论发生何种问题，我们都能及时记录、分析，并向用户提供一个相对优雅的反馈，而不是直接暴露技术细节，让用户一头雾水。

理论要掌握，实操不能落！以上关于《PHP自定义错误处理方法解析》的详细介绍，大家都掌握了吧！如果想要继续提升自己的能力，那么就来关注golang学习网公众号吧！