如果错误日志记录失败，您会怎么做？如何测试其在生产中的工作情况？
- 如果错误记录代码失败，您该怎么办？
- 您如何确保其当前正常工作？
- 你怎么知道它是否不起作用？
- 您如何测试它在生产环境中的工作情况？
- 如果其他一切都失败了，我应该抛出异常吗？
下面的代码使用 Microsoft 的企业库日志记录应用程序块。 如何让它变得“更好”？
using Microsoft.Practices.EnterpriseLibrary.Logging;
class Program
{
static void Main(string[] args)
{
try
{
// Trying to write some data to the DB
...
}
catch (Exception ex)
{
LogHelper.LogException(ex, "Trying to write to the DB");
}
}
}
public class LogHelper
{
public static void LogException(Exception ex, string exceptionType)
{
try
{
// Simplified version, only logging the message
Logger.Write(exceptionType);
}
catch
{
// What do you do here???
}
}
}
- What do you do if you're error logging code fails?
- How do you make sure that its currently working?
- How do you know if its not working?
- How do you test that its working in a production environment?
- Should I throw an exception if all else fails?
The code below uses Microsoft's Enterprise Library Logging Application Block. How do you make it "better"?
using Microsoft.Practices.EnterpriseLibrary.Logging;
class Program
{
static void Main(string[] args)
{
try
{
// Trying to write some data to the DB
...
}
catch (Exception ex)
{
LogHelper.LogException(ex, "Trying to write to the DB");
}
}
}
public class LogHelper
{
public static void LogException(Exception ex, string exceptionType)
{
try
{
// Simplified version, only logging the message
Logger.Write(exceptionType);
}
catch
{
// What do you do here???
}
}
}
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（3）
我的应用程序通常会在出现错误时执行两件事。 第一种是将其写入本地日志文件（即使它也使用某种类型的数据库日志记录）。 然后，它会将错误的电子邮件发送到为支持而设置的通讯组列表。
因此，如果数据库日志写入失败，错误仍然存在于本地日志文件中，并且也会通过电子邮件发送。
如果电子邮件发送失败，错误仍会记录下来，以便您稍后解决问题。
恕我直言，只有对于极其关键的任务应用程序来说，获得比这更高的容错能力才值得付出努力。
My apps usually do two things on an error. The first is to write it to a local log file (even if it uses some type of database logging as well). Then it sends an e-mail of the error to a distribution list set up for support.
So if the database log write fails, the error is still in the local log file and also sent via e-mail.
If the e-mail fails, the error is still logged so you can troubleshoot the problem later.
Getting more fault tolerant than that would only be worth the effort for extremely mission critical applications, IMHO.
请参阅我的相关问题中的答案：
如果其他一切都失败了，请在您的 catch 块中使用“最后手段日志记录”。 将异常记录到文本文件中不太可能失败的位置。 如果最后的手段日志记录因抛出另一个异常而失败，您可以吞掉该异常，或者终止您的应用程序并将错误显示为消息框。
在这种特定（例外）情况下，吞下异常是不终止应用程序的唯一方法。
See the answers in my related question:
If everything else fails, have a 'last resort logging' in your catch block. Log the exception to a text file in a location where this is highly unlikely to fail. If this last resort logging fails by throwing another exception, you can either swallow that exception, or terminate your app and display the error as a message box.
In this specific (exceptional) case, swallowing the exception is the only way to not terminate the app.
我写了一个日志文件，并将一封电子邮件发送到一个永远不会消失的常用地址。 两者都不是防弹的，但我认为如果我们的邮件系统出现故障或电子邮件服务器发生变化，我们会知道这一点。 我确实有一些应用程序可以写入数据库和平面文件并发送电子邮件。 所以这三个中的一个就可以工作了。 我发现我的一个应用程序正在写入数据库以获取日志，并且在捕获中它正在写入同一个数据库，我发现它的唯一方法是应用程序由于数据库连接中的一些更改而失败。 我确保修改 catch 语句来处理电子邮件而不是数据库。 我对平面文件的唯一问题是文件系统存储，我们有很多应用程序为日志写入平面文件，因此我们不断备份并保存它们，或者只是简单地删除它们。
I write a log file as well as have an email sent to a common address that will never go away. Neither are bullet proof but I would think that if our mail system is down or the email server changes we would know about it. I do have some apps that write to both a database and a flat file and send the email. So one of the 3 is going to work. I found one of my apps was writing to a db for the log and in the catch it was writing to the same db and the only way I found it was the app was failing because of some changes in the db connection. I made sure to modify that catch statement do the email instead of the db. The only problem I have with flat files is file system storage, we have a lot of applications that write flat files for logs so we are constantly backing them up and saving them or just plain deleting them.