我刚刚看到一个关于try-catch的问题,哪些人(包括Jon Skeet)认为空catch块是一个非常糟糕的主意?为什么呢?在任何情况下,空接点都不是错误的设计决策吗?

我的意思是,例如,有时你想从某个地方(webservice,数据库)获得一些额外的信息,你真的不关心你是否会得到这个信息。所以你试着获取它,如果发生了什么,没关系,我只会添加一个“catch (Exception ignored){}”,仅此而已


当前回答

我认为如果你捕捉到一个特定的异常类型,你知道它只会因为一个特定的原因而被引发,并且你期待这个异常,并且真的不需要对它做任何事情,这是可以的。

但即使在这种情况下,也可能需要调试消息。

其他回答

空的catch块通常被放入,因为编码器并不真正知道他们在做什么。在我的组织中,一个空的catch块必须包含一个注释,说明为什么不处理异常是一个好主意。

与此相关的是,大多数人不知道try{}块后面可以跟catch{}或finally{},只有一个是必需的。

通常空的try-catch是一个坏主意,因为您正在默默地接受一个错误条件,然后继续执行。偶尔这可能是正确的做法,但通常这是一个迹象,表明开发人员看到了异常,不知道该如何处理,因此使用空捕获来消除问题。

这就相当于在引擎警示灯上贴上黑色胶带。

我相信如何处理异常取决于您正在使用的软件的哪个层:

你不应该有一个空的catch块。这就像隐藏一个你知道的错误。至少,您应该为日志文件编写一个异常,以便稍后在时间紧迫时查看。

我认为如果你捕捉到一个特定的异常类型,你知道它只会因为一个特定的原因而被引发,并且你期待这个异常,并且真的不需要对它做任何事情,这是可以的。

但即使在这种情况下,也可能需要调试消息。

这可能从来都不是正确的事情,因为您正在默默地传递每个可能的异常。如果有您期望的特定异常,那么您应该测试它,如果它不是您的异常则重新抛出。

try
{
    // Do some processing.
}
catch (FileNotFound fnf)
{
    HandleFileNotFound(fnf);
}
catch (Exception e)
{
    if (!IsGenericButExpected(e))
        throw;
}

public bool IsGenericButExpected(Exception exception)
{
    var expected = false;
    if (exception.Message == "some expected message")
    {
        // Handle gracefully ... ie. log or something.
        expected = true;
    }

    return expected;
}