问题描述
public void EatDinner(string appetizer, string mainCourse, string dessert)
{
try
{
// Code
}
catch (Exception ex)
{
Logger.Log("Error in EatDinner", ex);
return;
}
}
当特定方法发生异常时，应该我正在记录？
When an exception occurs in a specific method, what should I be logging?
我在我使用的代码中看到了很多上面的代码。在这些情况下，我总是必须与遇到错误的人进行交谈，以了解他们在做什么，逐步通过代码，并尝试重现错误。
I see a lot of the above in the code I work with. In these cases, I always have to talk to the person who experienced the error to find out what they were doing, step through the code, and try to reproduce the error.
有没有最佳的做法或方法，我可以最小化这些额外的工作？我应该在每个方法中记录参数吗？
Is there any best practices or ways I can minimize all this extra work? Should I log the parameters in each method like this?
Logger.Log("Params: " + appetizer + "," + mainCourse + "," + dessert, ex);
有没有更好的方法来记录当前的环境？如果我这样做，我需要为我应用程序中的每个方法写出所有这些东西吗？有没有关于这样的情况的最佳做法？
Is there a better way to log the current environment? If I do it this way, will I need to write out all this stuff for each method I have in my application? Are there any best practices concerning scenarios like this?
推荐答案
作为一般规则，我会说努力记录所有重现导致错误的事件过程所必需的信息。请注意，您不一定需要记录 catch 块内的所有内容：您可以在代码中放置（调试）日志语句，内部调用的方法等等跟随正在发生的事情直接在异常之前。此外，您应该将信息放入异常本身，以了解导致它的确切症状。
As a general rule, I would say strive to log all the information necessary to reproduce the course of events leading to an error. Note that you don't necessarily need to log everything inside the catch block: you can put (debug) log statements around in your code, inside methods called etc. which enable you to follow what was going on directly before the exception. Also, you should put information into the exception itself about the exact symptom what caused it.
IMHO通过所有代码添加日志语句到处都可能是过度的 - 或在至少在现实生活中不具成本效益。相反，专注于最关键的代码部分，以最大限度地提高您的努力的回报。这些代码部分通常是大多数错误发生的地方，和/或大部分修改（将要完成）。所以在实践中，只要您需要触摸一段代码，请考虑日志记录，检查已经存在的日志语句（如果有的话），检查异常处理（如果有的话 - 我经常看到的代码就像你的例子那样）只是吞下异常捕获，但是在我们的遗留代码中甚至空白或自动生成 catch 块...所有这些都可能使应用程序处于未定义的状态，这是一个错误的状态） ，并考虑是否已经有足够的您重现故障，并了解如果发生错误发生了什么。然后尽可能地改善它，并且可以合理地努力。
IMHO going through all the code to add log statements everywhere may be overkill - or at the least, not cost effective in a real life project. Instead, focus on the most critical code parts to maximize returns from your efforts. These code parts are typically where the most bugs happen and/or the most modifications are (going to be) done. So in practice whenever you need to touch a piece of code, think about logging, check the log statements already present there (if there is any), check exception handling (if there is any - I routinely see not only code like your example which simply swallows the exception caught, but even empty or autogenerated catch blocks in our legacy code... all of these may leave the application in undefined state, which is a BAD THING), and think about whether what is already there is enough for you to reproduce failures and understand what happened if an error occurs. Then improve it as much as you need to and can with a reasonable effort.
它也有助于与你的队友讨论这个话题，并尝试粗略的项目约定，如何记录事件，如何处理异常等。这可能会节省很多时间，否则花费在追逐错误和/或改进您的同事所产生的代码： - （
It also helps to discuss this topic with your teammates and try to work out a rough project convention of how to log events, how to handle exceptions etc. This might save you a lot of time otherwise spent on chasing bugs and/or improving code produced by your very coworkers :-(
这篇关于发生异常时要记录什么？的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持！