可能重复:
Why are empty catch blocks a bad idea?
Is there any valid reason to ever ignore a caught exception
你是否知道空挡块不是绝对邪恶的任何情况?
try
{
...
// What and When?
...
}
catch { }
答案 0 :(得分:7)
对此有很多疑问,请试着看看:
Why are empty catch blocks a bad idea?
从该帖子接受的答案:
通常空的try-catch是个坏主意,因为你正在静默地吞下一个错误条件,然后继续执行。偶尔这可能是正确的做法,但通常这表明开发人员看到了异常,不知道如何处理它,因此使用空捕获来解决问题。
这相当于将黑色胶带放在发动机警告灯上。
答案 1 :(得分:1)
看一下this,它基本上将你可能遇到的异常分解为四个类别,其中没有一个应由空的catch块处理。
答案 2 :(得分:1)
我会说你至少应该提供某种评论或记录消息,表明你在try {}中放入的内容引发了异常,这就是你没有做任何事情的原因。
答案 3 :(得分:1)
我将它用于一些自编写的库,其中我需要某种bool TrySomething(out object)
函数或object TrySomething()
,其中底层调用不提供任何其他机制作为异常。在这种情况下,我使用一个空的catch块并返回false
或null
(取决于函数签名)。
public bool TrySomething(out object destination)
{
try
{
destination = DoSomething();
return true;
}
catch
{}
return false;
}
答案 4 :(得分:1)
公理:
空捕获块绝对是邪恶的
不要试图找到解决方法。只是试图找到他们不是绝对邪恶的案例意味着你浪费宝贵的大脑周期。不要试图在这里找到一个模式,想“嗯,我应该把空挡块放在这里吗?”
如果你在某人的代码中偶然发现了一个空的catch块,你只是偶然发现了technical debt。修理它。即使只是在一个空的catch块中添加一个日志语句,你也会让这个世界变得更加美好。