扩展异常类和日志/电子邮件答案

【问题标题】：Extending Exception class and logging / emailing扩展异常类和日志/电子邮件
【发布时间】：2012-05-21 05:08:47
【问题描述】：

我正在尝试扩展异常类，以便在传递指定错误代码时记录和发送电子邮件 - 我希望抛出的所有错误都属于自定义异常类型以进行诊断 - 我遇到的问题是如何当电子邮件或记录器类因任何原因失败时，我应该解决吗

我想我需要在电子邮件或记录器类的情况下恢复为默认异常，而对于其他所有情况，将使用自定义异常

任何帮助将不胜感激

【问题讨论】：

标签： php exception-handling

【解决方案1】：

我遇到的问题是，当电子邮件或记录器类因任何原因失败时，我该如何解决

将邮件/日志尝试包装在 try-catch 块中。

try{
    myExceptionClass::logException( $customException );
    myExceptionClass::emailNotification( $adminEmail );
}catch( Exception $e ){
    exit( "dangit" );
}

理想情况下，您的错误处理永远不会允许这种情况实际发生，因此您应该能够将其视为“边缘情况”。我假设你仍然允许服务器记录你的 PHP 错误，所以你仍然可以使用一些东西来发现这样的问题。

【讨论】：

是的，我试过了，但问题是我试图在错误处理程序中使用相同的文件编写器和电子邮件类 - 正如您可以想象的那样，如果这些类中的任何一个发生异常这是一个递归调用 - 将异常处理程序的电子邮件和日志记录与应用程序其余部分使用的处理程序分开的最佳方式是什么？
正确 - 显然，如果您的错误处理程序有问题，您不想再次尝试使用它。您需要在 catch{} 块中实现不同的（可能更简单）逻辑。这就是我所说的“希望这是一个边缘案例”的意思——你不希望经常出现这样的错误。您的 catch 需要比您的正常错误处理更简单/更健壮。
...您也可以使用set_exception_handler() 作为后备来捕捉任何漏掉其他问题的问题。在开发过程中，我的会打印有用的错误消息和堆栈跟踪。当网站上线时，它只是将用户重定向到错误页面。（通过检查 Apache 的日志很容易看出这种情况何时发生。）对于用户来说，这比看到一个“损坏”的页面要好——但老实说，我认为没有任何用户有机会看到一个 :)
@digital_paki 你明白了吗？