将错误转换为异常：设计缺陷？ [英] Converting errors to exceptions: design flaw?

问题描述

我最近遇到了一些使用自定义错误处理程序将任何PHP错误转换为广义应用程序异常的代码。还定义了一个自定义异常处理程序，它将在异常范围内记录异常。示例：

I came across some code recently that used a custom error handler to turn any PHP errors into an generalized application exception. A custom exception handler was also defined that would log the exception if it was within a particular error code range. Example:

class AppException extends Exception
{

}

function error_handler($errno, $errstr, $errfile, $errline)
{
    throw new AppException($errstr, $errno);
}

function exception_handler($exception)
{
    $min = ...;
    $max = ...;

    if ($exception->getCode() >= $min && $exception->getCode() <= $max)
    {
        // log exception
    }
}

set_error_handler('error_handler');
set_exception_handler('exception_handler');

$a[1]; // throws exception

问题是我看到的东西如下：

The problem is that I saw things like:

try
{
    do_something();
}
catch (AppException $exception)
{
}

$ b $这意味着实际编程错误和异常行为之间没有区别。进一步挖掘，我遇到了一些代码设计的部分代码：PHP错误代表异常行为，如：

Which implies that there is no distinction between actual programming errors and "Exceptional" behavior. Upon further digging, I came across parts of the code that were designed around the idea that PHP errors represented "Exceptional" behavior such as:

...

function my_function($param1, $param2)
{
    // do something great
}

try
{
    my_function('only_one_param');
}
catch (AppException $exception)
{
}

哪个最终会出现模糊错误和应用程序界面的设计。

Which ends up obfuscating errors and the design of the application's interface.

您对这种方式处理错误有什么看法？是否值得将PHP的本机错误转化为异常？在上述情况下，您如何处理代码库？

What is your opinion on handling errors this way? Is it worth turning PHP's native errors into exceptions? What do you do in situations like the above where a codebase is designed around this idea?

推荐答案

个人而言，我一直都这样做。唯一的区别是，在我的 error_handler 函数中，我检查错误是否首先是$ code> E_NOTICE 如果它不是（我记录通知）...

Personally, I do this all the time. The only difference is that in my error_handler function, I check to see if the error is an E_NOTICE first, and only throw if it is not (I log the notice anyway)...

我会将 AppException 更改为某事这扩展了 ErrorException ...有些东西像： PhpRuntimeErrorException扩展ErrorException 你只用于PHP错误...原因是这样，它更易于阅读（更简单的说，一个 PhpRuntimeErrorException 不需要弄清楚它在哪里抛出）。另一个原因是， ErrorException 将存储生成行/文件/ etc信息，它不会存储在别处（因为回溯从 throw line）...

I would change the AppException to something that extends ErrorException... Something like: PhpRuntimeErrorException extends ErrorException which you ONLY use for PHP errors... The reason is so that it's more readable (it's easier to tell what a PhpRuntimeErrorException is without needing to figure out where it's thrown). The other reason, is that the ErrorException will store the generating line/file/etc information, where it would not be stored elsewhere (since the backtrace starts from the throw line)...

那么你可以像这样尝试代码：

So, then you can "try" code like this:

try {
    $f = fopen('foo.bar', 'r');
    $ret = '';
    while ($data = fread($f)) {
        $ret .= process($data);
    }
    fclose($f);
    return '';
} catch (PHPRuntimeErrorException $e) {
    throw new RuntimeException('Could not open file');
} catch (ProcessException $e) {
    fclose($f);
    throw new RuntimeException('Could not process data');
}
return $ret;

我也使我的默认异常处理程序生成一个500服务器错误页面。这是因为任何例外应该被捕获，如果不是，它真的是一个服务器错误...

I also make my default exception handler generate a 500 server error page. That's because any exceptions should be caught, and if they were not, it really is a server error...

只是我的经验和意见...

Just my experience and opinion...

这篇关于将错误转换为异常：设计缺陷？的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！