在维护我同事的代码时，甚至有人声称自己是高级开发人员，我经常看到以下代码:
try
{
//do something
}
catch
{
//Do nothing
}
或者有时他们将日志信息写入日志文件，例如下面的try catch块
try
{
//do some work
}
catch(Exception exception)
{
WriteException2LogFile(exception);
}
我只是想知道他们所做的是不是最好的做法?这让我很困惑，因为在我看来，用户应该知道系统发生了什么。
当前回答
我可以告诉你:
代码片段#1是不可接受的，因为它忽略了异常。(它像什么都没发生一样吞下去)。
所以不要添加不做任何事情或只是重新抛出的catch块。
Catch块应该增加一些价值。例如，向最终用户输出消息或记录错误。
不要对正常的流程序逻辑使用异常。例如:
例如输入验证。<-这不是有效的例外情况，而是你应该写方法IsValid(myInput);检查输入项是否有效。
设计代码以避免异常。例如:
int Parse(string input);
如果我们传递一个不能解析为int的值，这个方法会抛出一个异常，我们可以这样写:
bool TryParse(字符串输入，输出int结果);<-该方法将返回布尔值，表示解析是否成功。
也许这有点超出了这个问题的范围，但我希望这将帮助您在涉及try {} catch(){}和异常时做出正确的决定。
其他回答
更好的方法是第二种(指定异常类型的方法)。这样做的好处是，您知道这种类型的异常可以发生在您的代码中。您正在处理这种类型的异常，您可以继续。如果出现任何其他异常，那么这意味着有错误，这将帮助您找到代码中的错误。应用程序最终会崩溃，但你会知道你错过了什么(bug)，需要修复。
没有任何参数的捕获只是简单地吃掉异常，没有任何用处。如果发生致命错误怎么办?如果不带参数地使用catch，就无法知道发生了什么。
catch语句应该捕获更具体的异常，如FileNotFoundException，然后在最后捕获Exception，它将捕获任何其他异常并记录它们。
留下空白的catch块是最糟糕的做法。如果出现错误，最好的处理方法是:
登录到文件数据库等。 尝试在飞行中修复它(可能尝试做该操作的替代方式) 如果我们不能修复这个问题，那么就通知用户有错误，当然还要中止操作
最佳实践是在错误发生时抛出异常。因为发生了一个错误，它不应该被隐藏。
但在现实生活中，你可以有几种情况想要隐藏它
您依赖于第三方组件，并且希望在出现错误时继续执行程序。 您有一个业务案例，需要继续进行，以防出现错误
我知道这是一个老问题，但这里没有人提到MSDN的文章，实际上是文档为我澄清了这个问题，MSDN在这方面有一个非常好的文档，当以下条件为真时，你应该捕获异常:
您已经很好地理解了异常可能被抛出的原因，并且可以实现特定的恢复，例如在捕获FileNotFoundException对象时提示用户输入一个新的文件名。 您可以创建并抛出一个新的、更具体的异常。
int GetInt(int[] array, int index)
{
try
{
return array[index];
}
catch(System.IndexOutOfRangeException e)
{
throw new System.ArgumentOutOfRangeException(
"Parameter index is out of range.");
}
}
您希望在将异常传递给其他处理之前对其进行部分处理。在下面的示例中，catch块用于在重新抛出异常之前向错误日志添加条目。
try
{
// Try to access a resource.
}
catch (System.UnauthorizedAccessException e)
{
// Call a custom error logging procedure.
LogError(e);
// Re-throw the error.
throw;
}
我建议阅读整个“异常和异常处理”部分以及异常的最佳实践。
