你知道空的 catch 块不是绝对邪恶的情况吗?
try
{
...
// What and When?
...
}
catch { }
你知道空的 catch 块不是绝对邪恶的情况吗?
try
{
...
// What and When?
...
}
catch { }
There are a lot of questions on this, try to look at:
Why are empty catch blocks a bad idea?
From that post's accepted answer:
Usually empty try-catch is a bad idea because you are silently swallowing an error condition and then continuing execution. Occasionally this may be the right thing to do, but often it's a sign that a developer saw an exception, didn't know what to do about it, and so used an empty catch to silence the problem.
It's the programming equivalent of putting black tape over an engine warning light.
我将它用于一些我需要某种bool TrySomething(out object)
函数或object TrySomething()
底层调用不提供任何其他机制作为例外的自写库。在这种情况下,我使用一个空的 catch 块并返回false
或null
(取决于函数签名)。
public bool TrySomething(out object destination)
{
try
{
destination = DoSomething();
return true;
}
catch
{}
return false;
}
公理:
空的 catch 块绝对是邪恶的
不要试图找到解决方法。仅仅通过试图找到它们不是绝对邪恶的案例就意味着你在浪费宝贵的大脑周期。不要试图在这里找到模式,想“嗯,我应该在这里放一个空的 catch 块吗?”
如果您在某人的代码中偶然发现了一个空的 catch 块,那么您只是偶然发现了技术债务。修理它。即使只是在一个空的 catch 块中添加一个日志语句,你也会让这个世界变得更美好。
看看这个,它基本上把你可能遇到的异常分为四类,没有一个应该由一个空的catch块来处理。
我会说您至少应该提供某种评论或记录消息,表明您在 try {} 中输入的内容引发了异常,这就是您不做任何事情的原因。