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

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


当前回答

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

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

其他回答

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

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

一般来说,这是一个坏主意,因为这是一个真正罕见的情况,即失败(更普遍的情况是例外情况)没有得到任何回应。最重要的是,空捕获块是使用异常引擎进行错误检查的人使用的常用工具,他们应该先发制人地进行错误检查。

说它总是不好是不真实的……这种情况很少发生。在某些情况下,您不关心是否存在错误,或者错误的存在以某种方式表明您无法对其采取任何措施(例如,当将以前的错误写入文本日志文件时,您得到一个IOException,这意味着您无论如何都不能写出新的错误)。

这与“不要使用异常来控制程序流”和“只在异常情况下使用异常”是密切相关的。如果执行了这些操作,那么只有在出现问题时才会出现异常。如果出现了问题,你也不想默默地失败。在不需要处理问题的罕见异常中,您至少应该记录异常,以防异常不再是异常。比失败更糟糕的是默默的失败。

第65项:不要忽视有效Java的例外:

空的catch块无法实现异常的目的 至少,catch块应该包含一个注释,解释为什么忽略异常是合适的。

如果你不知道在catch block中要做什么,你可以只记录这个异常,但不要让它空着。

        try
        {
            string a = "125";
            int b = int.Parse(a);
        }
        catch (Exception ex)
        {
            Log.LogError(ex);
        }