在维护我同事的代码时，甚至有人声称自己是高级开发人员，我经常看到以下代码:
try
{
//do something
}
catch
{
//Do nothing
}
或者有时他们将日志信息写入日志文件，例如下面的try catch块
try
{
//do some work
}
catch(Exception exception)
{
WriteException2LogFile(exception);
}
我只是想知道他们所做的是不是最好的做法?这让我很困惑，因为在我看来，用户应该知道系统发生了什么。
当前回答
您应该考虑这些异常的设计指南
异常抛出 使用标准异常类型 异常和性能
https://learn.microsoft.com/en-us/dotnet/standard/design-guidelines/exceptions
其他回答
更好的方法是第二种(指定异常类型的方法)。这样做的好处是，您知道这种类型的异常可以发生在您的代码中。您正在处理这种类型的异常，您可以继续。如果出现任何其他异常，那么这意味着有错误，这将帮助您找到代码中的错误。应用程序最终会崩溃，但你会知道你错过了什么(bug)，需要修复。
留下空白的catch块是最糟糕的做法。如果出现错误，最好的处理方法是:
登录到文件数据库等。 尝试在飞行中修复它(可能尝试做该操作的替代方式) 如果我们不能修复这个问题，那么就通知用户有错误，当然还要中止操作
你唯一应该让用户担心代码中发生的事情的时候是他们是否可以或需要做一些事情来避免这个问题。如果他们可以更改表单上的数据、按下按钮或更改应用程序设置以避免这个问题，请让他们知道。但是用户无法避免的警告或错误只会让他们对你的产品失去信心。
异常和日志是为您，即开发人员，而不是最终用户准备的。当您捕捉到每个异常时，了解正确的做法要比仅仅应用一些黄金规则或依赖于应用程序范围的安全网要好得多。
盲目的编码是唯一一种错误的编码。事实上，您觉得在这些情况下可以做一些更好的事情，这表明您对良好的编码进行了投资，但避免试图在这些情况下确定一些通用规则，并首先了解抛出某些东西的原因，以及您可以做些什么来从中恢复。
对于异常，我尝试如下:
首先，我捕获特殊类型的异常，如除零、IO操作等，并根据这些编写代码。例如，除以0，这取决于我可以提醒用户的值的出处(例如，一个简单的计算器在中间计算(而不是参数)中到达一个除以0)，或者静默地处理这个异常，记录它并继续处理。
然后我尝试捕获剩余的异常并记录它们。如果可能，允许执行代码，否则提醒用户发生错误，并要求他们发送错误报告。
在代码中，是这样的:
try{
//Some code here
}
catch(DivideByZeroException dz){
AlerUserDivideByZerohappened();
}
catch(Exception e){
treatGeneralException(e);
}
finally{
//if a IO operation here i close the hanging handlers for example
}
To me, handling exception can be seen as business rule. Obviously, the first approach is unacceptable. The second one is better one and it might be 100% correct way IF the context says so. Now, for example, you are developing an Outlook Addin. If you addin throws unhandled exception, the outlook user might now know it since the outlook will not destroy itself because of one plugin failed. And you have hard time to figure out what went wrong. Therefore, the second approach in this case, to me, it is a correct one. Beside logging the exception, you might decide to display error message to user - i consider it as a business rule.
