为什么我不能只写一个没有捕获或最终的尝试？ [关闭]

Question

有时我这样做，我也看到其他人也这样做：

VB：

Try
    DontWannaCatchIt()
Catch
End Try

C#：

try 
{ 
    DontWannaCatchIt();
} 
catch {}

我知道我应该抓住每一个重要的异常 我期待并对此采取一些措施，但有时并不重要 -还是我做错了什么？

try 块的这种用法是否不正确，并且至少有一个 catch 或 finally 块的要求表明了这一点？

更新：

现在我明白了其中的原因，我至少应该对空的 catch 块发表评论，以便其他人了解它为什么是空的。我也应该只捕获我期望的异常。

幸运的是，我正在用 VB 编写代码，所以我可以一口气写出来：

Catch ex As Exception When TypeOf ex Is IOException _
                    OrElse TypeOf ex Is ArgumentException _
                    OrElse TypeOf ex Is NotSupportedException _
                    OrElse TypeOf ex Is SecurityException _
                    OrElse TypeOf ex Is UnauthorizedAccessException
    'I don't actually care.
End Try

Answer 1

没有 catch 或 finally 无效。空的 catch 或 finally 是有效的。空catch意味着你不关心异常，你只是尝试做一些事情，如果它不起作用也没关系，你只是想继续。例如在清理功能中很有用。

Answer 2

另外，如果您不需要对错误采取措施，也许您应该指定程序必须忽略的异常类型。

如果你必须忽略每一个异常，我不明白为什么你不能以这种方式使用 try/catch。

Answer 3

我听说的原因是，如果您的尝试因任何原因失败，让您控制错误响应比让框架控制它更可取，即黄屏或错误 500。

Answer 4

这通常是一个错误。异常信号，嗯，异常行为；当抛出异常时，它应该意味着出现问题。因此，继续正常的程序流程，就好像没有出错一样是隐藏错误的一种方式，一种拒绝的形式。相反，请考虑您的代码应该如何处理异常情况，并编写代码来实现这一点。由于您掩盖了它而传播的错误比立即出现的错误更更难调试。

Answer 5

这对您来说并不容易，因为大多数开发人员认为这是不好的做法。

如果后来有人向DontWannaCatchIt() 的主体添加了一个方法调用，确实抛出了一个值得捕获的异常，但它被你的空 catch 块吞噬了怎么办？如果有一些您实际上想要捕获但当时没有意识到的异常怎么办？

如果您绝对必须这样做，请尽量具体说明您要捕获的异常类型。如果没有，也许记录异常是一种选择。

Answer 6

如果你只用 try 编写代码会怎样

try
{
   int j =0;
   5/j;
}

这相当于写

 int j =0;
   5/j;

所以写 try 没有任何意义，它只会增加你的行数。

现在如果你用空的 catch 或 finally 编写 try ，你就是在明确地指示运行时以不同的方式表现。

这就是为什么我认为空的 try 块是不可能的。

Answer 7

如果你不想抓住它，你为什么首先使用try？

try 声明表示您认为可能会出错，catch 表示您可以充分处理出错的情况。

所以在你的估计中：

try
{
    //Something that can go wrong
}
catch
{
    //An empty catch means I can handle whatever goes wrong. If a meteorite hits the
    //datacenter, I can handle it.
}

这个 catch 会吞下任何发生的异常。您对自己的代码有信心，能够优雅地处理任何出错的事情吗？

最好的办法（为了你和你的维护程序员的理智）是明确说明你可以优雅地处理：

try
{
    //Something that could throw MeteoriteHitDatacenterException
}
catch (MeteoriteHitDatacenterException ex)
{
    //Please log when you're just catching something. Especially if the catch statement has side effects. Trust me.
    ErrorLog.Log(ex, "Just logging so that I have something to check later on if this happens.")

}

Answer 8

是的，这是不正确的。就像goto：每 100 KLoc 一个就可以了，但如果你需要很多，那你就错了。

在没有任何反应的情况下吞下异常是错误处理中最糟糕的事情之一，它至少应该是明确的：

try  
{      
   DontWannaCatchIt(); 
}  
catch 
{
    // This exception is ignored based on Spec Ref. 7.2.a,
    // the user gets a failure report from the actual results, 
    // and diagnostic details are available in the event log (as for every exception)
} 

---

远观：

错误处理是一个方面：在某些情况下，需要抛出错误并向上传播调用堆栈（例如，您复制文件，复制失败）。

在不同的上下文中调用相同的代码可能需要跟踪错误，但操作要继续（例如，复制 100 个文件，并带有指示哪些文件失败的日志）。

即使在这种情况下，空的 catch 处理程序也是错误的。

在大多数语言中，除了在循环中使用 try+catch 并在 catch 处理程序中构建日志之外，没有其他直接的实现。 （不过，您可以构建一个 mroe 灵活的机制：拥有一个可以抛出或隐藏消息的每个调用线程处理程序。但是，如果没有直接的语言支持，与调试工具的交互会受到影响。）

---

一个明智的用例是从X() 实现TryX()，但这必须返回有问题的异常。

Answer 9

存在错误，已被抛出，需要去某个地方。正常代码流已中止，需要清洁风扇。

没有捕获块 = 不确定状态。代码应该去哪里？应该怎么做？

一个空的 catch 块 = 通过忽略它来处理错误。

注意：VBA 有一个卑鄙的“错误继续”...

Answer 10

不，您应该不捕获每个重要的异常。捕获和忽略您不关心的异常是可以的，例如 I/O 错误，如果您无法纠正它并且您不想费心将其报告给用户。

但您需要让 StackOverflowException 和 OutOfMemoryException 等异常传播。或者，更常见的是NullReferenceException。这些异常通常是您没有预料到、无法从中恢复、不应从中恢复且不应被抑制的错误。

如果您想忽略异常，那么很好在代码中为该特定异常显式编写一个空的 catch 块。这清楚地表明您正在忽略哪些异常。非常正确地忽略异常是一种选择加入程序，而不是选择退出程序。拥有一个“忽略所有异常”功能，然后可以覆盖该功能以不忽略特定类型，这将是一个非常糟糕的语言功能。

您如何知道哪些类型的异常很重要且不应被捕获？如果有你不知道的例外怎么办？你怎么知道你最终不会隐藏你不熟悉的重要错误？

try
{
}
// I don't care about exceptions.
catch
{
}
// Okay, well, except for system errors like out of memory or stack overflow.
// I need to let those propagate.
catch (SystemException exception)
{
    // Unless this is an I/O exception, which I don't care about.
    if (exception is IOException)
    {
        // Ignore.
    }
    else
    {
        throw;
    }
}
// Or lock recursion exceptions, whatever those are... Probably shouldn't hide those.
catch (LockRecursionException exception)
{
    throw;
}
// Or, uh, what else? What am I missing?
catch (???)
{
}