trigger_error与抛出异常

Question

问了一个类似的问题here，但由于答案没有回答我的问题，我问：

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

我正在更新this library，这个问题与send方法有关，但是已经足够了。这是我的理由：

• 如果未设置API密钥常量，则不是可捕获的错误。这是一个编程错误，应该这样对待。

• 如果电子邮件地址无效，则应该可以捕获。这很可能是用户错误。

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

Answer 1

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

由于我的所有PHP 错误（注意：不是异常，但警告，通知，致命等）都记录在生产中，我认为trigger_error是一种方便的方法来获取东西进入上述日志。

以下是一个例子：

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

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

Answer 2

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

Answer 3

他们都有自己的用途。通常，我会向开发人员提供trigger_error（），因为在大多数生产环境中，错误报告都会被关闭;然后，由于大多数应用程序错误可能来自糟糕的用户输入或基于用户输入/操作的不良结果，因此我抛出异常以更好地控制应用程序（以允许应用程序恢复的方式处理这些异常，以及（如有必要，以合理的方式通知用户发生的事情。

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