通过电子邮件通知错误的更好做法是什么答案

【问题标题】：What is better practice for error notification by email通过电子邮件通知错误的更好做法是什么
【发布时间】：2010-12-23 03:41:58
【问题描述】：

这个问题与语言无关。

我有一个循环处理请求的应用程序。在这个循环中，每个请求都会执行多个操作。这些操作位于 try / catch / log 块中。我现在将其扩展为通过电子邮件通知管理员严重错误。

这一切都很容易，除了一件事。我们依靠客户端来实现他们自己的电子邮件传递冗余，根据经验，我知道总会有一个客户端只有一个 SMTP 交换服务器，而且这必然会不时下降。

所以这是两难的：

场景 1（发送失败期间不处理错误） - 当我向管理员发送电子邮件并且 SMTP 关闭时，它将破坏应用程序（应用程序将停止运行，并且其他循环将停止处理，因为错误是unhandled) 这意味着本应对应用程序有益的错误报告突然变成了 99/100 请求未得到处理的原因，因为请求 1 存在问题。

场景 2（在发送失败期间处理异常） - 这意味着我将发送代码包含在 try/catch/log 块中，太棒了！应用程序处理所有请求 99，除了一个，但管理员现在没有通过电子邮件通知这一错误，因为当它尝试发送 SMTP 时，该错误被简单地记录到应用程序日志中，管理员没有'不要一次检查此日志数天（甚至数周），现在无法知道发生了错误。

那么，有没有一种双赢的方式来解决这个问题，或者我总是会不知所措，并且受到 SMTP 启动的摆布。请记住，管理电子邮件服务器冗余超出了我们的范围。

【问题讨论】：

标签： email smtp exchange-server

【解决方案1】：

扩展方案 2 以记录应用程序日志中的哪些条目未通过电子邮件发送，并定期轮询此日志以查找未发送的条目并尝试重新发送它们 - 最终 smtp 服务将再次可用。（您可能希望阻止任何重新发送的错误返回重新发送队列......）

【讨论】：

【解决方案2】：

我建议“双赢”的方式是让一个服务器管理员真正管理服务器，而不是一个在他的邮件服务器关闭时完全无法访问的服务器管理员，并且没有事后不必费心检查它，看看他是否错过了任何通知。

【讨论】：