处理@抑制的错误的正确方法？答案

【问题标题】：Proper way to handle errors suppressed by @?处理@抑制的错误的正确方法？
【发布时间】：2019-03-04 06:17:10
【问题描述】：

如manual 中所述，如果错误来自@ 抑制，则调用error_reporting() 将返回0。但由于我的生产服务器始终设置为error_reporting(0)（在脚本之上），调用error_reporting() 将始终返回0。

我如何才能真正捕捉或区分合法错误与@ 抑制的错误？

现在我的错误处理程序是这样的：

if (error_reporting() == (E_ALL OR -1))
    echo 'display specific error';
elseif (error_reporting() == 0)
    echo 'display general error';

注意：这与我之前的question有关。

【问题讨论】：

标签： php error-handling suppress-warnings error-suppression

【解决方案1】：

Mu. 不应将 error_reporting 设置为 0，即使在生产环境中也是如此。

在开发过程中，您需要将错误报告级别设置为尽可能高的级别，以便收到有关任何和所有错误或通知或弃用消息或可能在未来造成问题的问题的通知。

在生产中，您需要将错误报告级别设置为仅包括错误和警告，但不包括弃用通知之类的内容。这是为了让您的错误日志免受多余信息的影响，并能够有效地追踪生产错误。

因为您应该始终记录错误。

你不应该在生产中做的是在屏幕上显示错误。这就是ini_set('display_errors', true|false) 控制的内容。您仍然希望在生产中错误报告，只是将其写入日志文件。

【讨论】：

是的，我的错误总是被记录下来，但我想通知用户发生了错误。所以我猜想在记录后放入错误处理程序的正确方法是：if (error_reporting() == 0) { // do nothing } else { echo 'general error message'; } 这是推荐的吗？
错误处理程序的工作不是进行任何用户交互。错误报告级别是一个全局值，它指定您（开发人员）有兴趣了解的错误类型。它将错误过滤为“不感兴趣”和“感兴趣”。错误处理程序和/或那里的 ini 配置要么在屏幕上输出这些错误和/或将它们写入日志。这都是关于用户永远不会看到的技术错误。向用户显示某些内容是一项业务逻辑决策，不在此级别处理。
这类错误是在if (!someFunction()) { echo "Please try again."; } 级别完成的。 someFunction 这里可能会或可能不会产生错误/通知/警告，您的错误处理程序会将其写入日志和/或显示在屏幕上。但这与用户应该看到的内容完全不同。
我了解来自 3rd 方库或数据库连接失败的错误，除非由开发人员修复，否则用户无能为力？我们在哪里放置说有问题的一般错误，还不能继续？
诸如数据库连接失败之类的事情应该引发异常或exit带有错误代码的脚本，例如exit 1。这应该会导致 Web 服务器触发其500 响应代码行为并输出其错误页面。或者，您可以像if (!$db = connect()) { echo 'Error!'; exit 1; } 那样手动处理。 – 错误处理程序实际上只涉及与开发人员相关的详细错误信息，而不涉及面向用户的错误处理。