trigger_error 与抛出异常答案

【问题标题】：trigger_error vs. throwing exceptionstrigger_error 与抛出异常
【发布时间】：2011-04-28 20:53:26
【问题描述】：

here 提出了类似的问题，但由于答案没有回答我的问题，我在问：

我几乎从未使用过trigger_error，而是总是抛出异常，因为在我看来错误是遗留问题。但我改变了主意，我认为它们可以共存。在某些情况下，触发错误更有意义。

我正在更新this library，这个问题涉及send 方法，但足够笼统。这是我的推理：

如果未设置 API 密钥常量，则这不是可捕获的错误。这是一个编程错误，应该这样对待。
如果电子邮件地址无效，则应该可以捕获。这很可能是用户错误。

我是疯子吗？这是不必要和烦人的，还是有意义的？

【问题讨论】：

错误不可恢复，异常可重试。出现错误后无法继续，但通常可以忽略异常。如果您无法写入磁盘，那就是错误。如果数据库无法连接，那就是错误。如果没有设置环境，那就是错误。但如果 API 服务关闭，这是一个例外 - 稍后再试。当然，您对不可恢复的想法是主观的。
使用 trigger_error() 的一种情况是当您只想发出 E_USER_NOTICE 或 E_USER_WARNING 时，它们都不会停止程序执行。例如，使用您的库的人设置了一个参数，虽然从技术上讲不是程序错误，但很可能不会产生预期的结果。发出警告或通知似乎是处理该问题而不是停止执行的正确方法。

标签： php exception exception-handling error-handling

【解决方案1】：

它们都有各自的用途。通常，我将 trigger_error() 用于开发人员，因为在大多数生产环境中，错误报告是关闭的；然后，由于大多数应用程序错误可能来自错误的用户输入或基于用户输入/操作的不良结果，我抛出异常以更好地控制应用程序（以允许应用程序恢复的方式处理这些异常，并且（如有必要）以合乎逻辑的方式通知用户发生的事情。

编辑：该示例基于网络应用程序；对于非用户控制的应用程序中的任何可变数据也可以这样说。

【讨论】：

【解决方案2】：

如果我使用该库，我真的很讨厌同时使用 try-catch 块和旧式错误检查。即使缺少 API 密钥导致库无法使用，它仍然是应用程序的一部分。

【讨论】：

if(some_function() == false) { // 错误，做点什么 } else { // 继续正常 }
我想你误解了我的意思。这是无法捕获的，没有任何返回 false。它应该被视为语法错误
您应该将决定是否可以捕捉到使用您的库的程序员。而且无论如何，缺少API密钥不是编程，而是配置错误。
我用了一段时间后，不得不同意你的看法。
请始终抛出异常，不要触发错误！让开发人员决定它是否可以捕获。开发人员可能出于某种原因决定将 API 密钥配置留给最终用户。错误的配置将导致应用程序无法使用并出现死屏，而不是能够向最终用户显示漂亮的错误消息。

【解决方案3】：

我同意你的区别，关于何时投掷和何时触发。对我来说，trigger_error 也是你想要记下的东西，但它对当前请求并不重要。例如。用于调试目的。

由于我所有的 PHP 错误（注意：不是异常，而是警告、通知、致命等）都记录在生产环境中，我认为trigger_error 是一种方便的方式来获取信息记录。

这是一个例子：

我正在使用 HTTP 客户端来访问我们集成的 API。当然，我使用的库是面向对象的 PHP，因此大量使用了异常。我在这里做各种各样的事情，我希望这个例子有意义：

HTTP 客户端库在实际请求失败时抛出异常——例如由于连接问题，例如超时等。当然我抓住了这个错误，但我没有将它提升给用户。我的包装器返回 false，这等于“临时问题”。在前端。
在我的catch() 块中，我使用trigger_error() 记录有关实际连接错误的调试信息。由于我在php.ini 中获得了error_log = syslog，因此所有这些信息都会发送到系统日志并最终发送到我的日志主机。

【讨论】：

你能澄清“对当前请求不重要”吗？如果没有设置 API 密钥，我认为这对当前请求来说是致命的
是的，需要的 API 密钥会引发异常。对于触发错误，如果某些内容无法验证，我会使用它 - 或者假设您解析某些内容并且解析器发出错误，但您仍然得到了您想要的任何内容，更多用于稍后的调试目的。
啊，所以trigger_error 不那么重要，更重要的是日志记录？这与我所争论的相反，但我想这也是有道理的。所以你从不使用try/catch 块？