php - 这种处理PHP错误的方法是否有任何 "gotchas"？

Question

我是 PHP 的新手，但在我看来 PHP 的错误处理有点贫民窟，错误和警告穿插在异常中(不要让我开始使用 die() )。因此，我不确定如何最好地创建、解释和处理我的应用程序中的所有错误情况。

我的总体攻击计划大致如下:

1. 将所有警告/错误转换为异常，使用 set_error_handler() 来包装错误。
2. 防御性编码，先发制人地检查我预计会出错的地方。只有当我不能直接处理错误时才抛出异常。通常的 try/catch block 将在需要时就位，以处理我自己不会抛出的异常。
3. 将我的整个应用程序(即我的 index.php 入口文件)包装在它自己的 try/catch 中。如果失败，我将抛出一个 HTTP 500 并显示一个合适的错误页面。大概这个页面将是一个单独的、预编译的文件，而不是包含页眉/正文/页脚的集合——这主要是为了让我仍然可以覆盖奇怪的异常，比如乱码模板文件。我想这就是为什么 Google 的 500 级错误页面看起来与他们推出的其他所有内容有很大不同的原因。
4. 作为 #2 和 #3 的必然结果，因为我希望预先处理所有事情，如果我决定抛出我自己的异常，我也希望不会捕获错误，而是让它一直冒泡到我的顶级处理程序。这里的想法是，如果我无法在它发生时处理它，那么我可能没有能力在其他任何地方处理它。我正在考虑为这些错误提供它们自己的子类 - 也许是 CriticalErrorException - 可以直接在我的日志中识别/生成电子邮件，以便我可以快速查看它。总的来说，我希望这些事情可能在开发中发生，但应该在生产中解决。
5. 任何到达顶部的错误都会记录在数据库中，并故障转移到日志文件。如上所述，严重错误会触发一封电子邮件。如果报告故障转移到文件 - 即存在数据库错误 - 这也会触发一封电子邮件。

我认为这很好地涵盖了大多数情况，但正如我所说，我是 PHP 的新手，所以我不知道是否有我忽略的极端情况或奇怪的行为。

我的计划有什么缺陷？我怎样才能克服它们？

Answer 1

总的来说，让意外异常冒泡到顶部 catch block 然后提供 HTTP 500 的策略很好(许多框架就是这样做的)。

我不太同意制作一个CriticalErrorException——也许您现在不希望捕获某些东西，但您可能会在将来扩展您的错误处理(可能面对额外的申请要求)。随便扔什么都是自然的。在大多数情况下，一个简单的 Exception 就可以了。

关于 PHP 错误:您不需要严格地将 E_ERROR 转换为异常(它无论如何都会终止您的应用程序，并且还会显示在错误日志中)。不过，您最好处理 E_NOTICE，因为通知几乎总是意味着代码有问题。

最后，当谈到引发警告的 PHP 函数时，我会这样说:

// Assume that php_function() raises E_WARNING and returns FALSE on error
// WARNING: if you have defined a custom error handler, IT WILL STILL BE CALLED
//          even though the @ operator suppresses the error
$result = @php_function($argument); // suppress error
if (!$result) {
    // error handling here
}

而不是这个:

try {
    $result = php_function($argument);
}
catch (Exception $ex) {
    // error handling here
}

原因是当您打算立即对错误使用react时，转换为异常并不能真正给您带来任何好处。相反，如果需要有关其错误处理策略的更多信息，第一个代码片段将“告诉”阅读它的开发人员查找 php_function 的文档。第二个代码片段将要求开发人员了解在您的应用中具体实现的错误处理。

更新:

我并不是说您应该使用 @ 来忽略函数调用产生的错误。我的意思是，当使用以这种方式运行的遗留 PHP 函数时，并且当您完全准备好处理错误并从中恢复时，当然不应再将其视为有关应用程序执行的“错误”。 在这种特定情况下，我建议抑制它，以免它也被报告。