在维护我同事的代码时，甚至有人声称自己是高级开发人员，我经常看到以下代码:
try
{
//do something
}
catch
{
//Do nothing
}
或者有时他们将日志信息写入日志文件，例如下面的try catch块
try
{
//do some work
}
catch(Exception exception)
{
WriteException2LogFile(exception);
}
我只是想知道他们所做的是不是最好的做法?这让我很困惑，因为在我看来，用户应该知道系统发生了什么。
当前回答
有时需要处理与用户无关的异常。
我的方法是:
在应用程序级别捕获未捕获的异常。在global.asax中)用于关键异常(应用程序可能没有用处)。这些例外情况我不太了解。只要在应用程序级别上登录它们，让系统完成它的工作。 捕捉“on place”并向用户显示一些有用的信息(输入错误的数字，无法解析)。 抓住位置，对边缘问题什么都不做，比如“我将在后台检查更新信息，但服务没有运行”。
它绝对不需要成为最佳实践。: -)
其他回答
有时需要处理与用户无关的异常。
我的方法是:
在应用程序级别捕获未捕获的异常。在global.asax中)用于关键异常(应用程序可能没有用处)。这些例外情况我不太了解。只要在应用程序级别上登录它们，让系统完成它的工作。 捕捉“on place”并向用户显示一些有用的信息(输入错误的数字，无法解析)。 抓住位置，对边缘问题什么都不做，比如“我将在后台检查更新信息，但服务没有运行”。
它绝对不需要成为最佳实践。: -)
没有任何参数的捕获只是简单地吃掉异常，没有任何用处。如果发生致命错误怎么办?如果不带参数地使用catch，就无法知道发生了什么。
catch语句应该捕获更具体的异常，如FileNotFoundException，然后在最后捕获Exception，它将捕获任何其他异常并记录它们。
我可以告诉你:
代码片段#1是不可接受的，因为它忽略了异常。(它像什么都没发生一样吞下去)。
所以不要添加不做任何事情或只是重新抛出的catch块。
Catch块应该增加一些价值。例如，向最终用户输出消息或记录错误。
不要对正常的流程序逻辑使用异常。例如:
例如输入验证。<-这不是有效的例外情况，而是你应该写方法IsValid(myInput);检查输入项是否有效。
设计代码以避免异常。例如:
int Parse(string input);
如果我们传递一个不能解析为int的值，这个方法会抛出一个异常，我们可以这样写:
bool TryParse(字符串输入，输出int结果);<-该方法将返回布尔值，表示解析是否成功。
也许这有点超出了这个问题的范围，但我希望这将帮助您在涉及try {} catch(){}和异常时做出正确的决定。
您应该考虑这些异常的设计指南
异常抛出 使用标准异常类型 异常和性能
https://learn.microsoft.com/en-us/dotnet/standard/design-guidelines/exceptions
第二种方法很好。
如果你不想显示错误，并通过显示运行时异常(即。错误)，这与他们无关，然后只记录错误，技术团队可以寻找问题并解决它。
try
{
//do some work
}
catch(Exception exception)
{
WriteException2LogFile(exception);//it will write the or log the error in a text file
}
我建议您对整个应用程序采用第二种方法。
