c# - Try Catch应该使用，除非永远不要使用？

Question

因此，我一直在研究应该如何进行try-catch-finally块，并且在阅读的每篇文章中都有一些相互矛盾的信息。有人可以澄清吗？

一个普遍的想法是，不要在代码中捕获不知道该如何处理的异常。如果没有其他异常捕获，异常将冒泡直到它可能到达全局异常处理程序。因此，此时您会向用户显示一条消息，指出发生了未知类型的异常，将其记录下来，等等。

现在看来，这是您唯一需要的异常处理程序？您不应该将其用于流程控制，因此您应该检查是否返回某些内容为null或无效导致异常并在代码中对其进行更正。即。测试null并对其进行一些处理，然后才能引起异常。

但是，还有其他一些事情，例如内存不足，您将无法测试它们，它只会在操作期间发生，并且会引发异常。但是我也将对此无能为力，因此这将被发送给全局处理程序。

我认为我缺少一些东西，例如在处理文件时，外部代码可能会抛出一些东西。文件未找到异常似乎经常出现，因此我会抓住它，并在finally块中正常关闭我打开的与其他代码/处理相关的所有内容，然后通知用户并立即将其记录在这里？

为什么要捕获异常的唯一原因是要确保该块的最后一部分能够确保在已知状态下关闭/确定该异常之前启动的所有内容？但是即使那样，您仍然希望在执行完这些任务后抛出此异常，以便全局异常处理程序通知用户，这时没有必要复制此代码吗？

因此，除了全局异常处理程序之外，您还可以针对这些情况尝试try-catch-finally块。

因此，假设我在这里遗漏了一些东西，则可能有可能您想要尝试捕获特定类型的异常，然后对其进行处理。我无法想到您想要在catch块中执行的任何操作，因为全局操作会记录/通知用户，并且如果您有异常，通常意味着没有任何代码可以继续处理。

有什么简单的方法可以知道哪些模块会抛出哪些异常？我认为我已读过的唯一方法是阅读MSDN或组件供应商文档，除了无法知道要查找的特定异常(无法确定为什么)之外，没有其他方法可以知道。

出现此问题是因为在我的应用程序中，我在try-catch块中有一段代码，最终导致发生异常时，这是因为对象为null或字符串无效。一旦我编写了处理这些情况的代码，就不再需要try-catch块，如果现在遇到异常，则代码无法执行任何恢复操作，因此应对其进行记录并让用户知道，以便对其进行修复。

但这与我一直在阅读和向我宣讲的东西背道而驰，错误的代码是没有try-catch块的代码。那么，这一切如何联系在一起，我在这里想念的是什么？

Answer 1

问题的第一部分是完全正确的:您应该只捕获知道如何处理的异常。否则，只要让它们冒泡，直到它们到达可以处理它们的代码为止。

(请注意，“句柄”并不表示“日志”或“显示错误”。它是指纠正导致异常的问题或以某种方式解决该异常。)

如果它们从未遇到可以处理它们的代码，或者它们是不可处理的异常(例如OutOfMemory)，则它们最终将到达全局未处理的异常处理程序。在这里，您将记录异常(如果适用)，向用户显示一般错误(如果适用)，并且经常(在不常见的情况下)终止应用程序。您不能像没有任何反应一样简单地继续操作-异常表明应用程序处于意外状态。如果尝试并继续，那只会崩溃，甚至更糟。

我认为我缺少一些东西，例如在处理文件时，外部代码可能会抛出一些东西。文件未找到异常似乎经常出现，因此我将捕获该异常，并在finally块中正常关闭我打开的与其他代码/处理相关的所有内容，然后通知用户并立即将其登录？

FileNotFound是您要在本地处理的异常的一个很好的例子。在尝试加载文件的相同方法(或UI代码中的上一层)中，您将拥有一个FileNotFound异常的catch块。如果合适，向用户显示友好的错误消息，并要求他们选择另一个文件。如果是内部代码，请放弃并尝试其他操作。无论您需要做什么。 FileNotFound在代码之外冒泡的原因很少。

这有点像使用异常进行流控制，但这是不可避免的。无法避免对I / O使用异常(或错误代码)，因此您只需要处理故障情况即可。您可以先尝试验证文件是否存在，然后再尝试打开它，但这不能解决竞标问题，因为在您运行验证代码与实际尝试打开文件之间，文件被删除或无法访问。因此，现在您要做的就是在两个地方复制错误处理代码，这几乎没有用。

您必须在本地处理类似FileNotFound的异常。离抛出的代码越远，您对它进行任何合理的选择的可能性就越小。

除了与I / O相关的异常外，另一个很好的例子是NotSupportedException。例如，如果尝试调用不支持的方法，则可能会遇到此异常。您可能会想要处理它，并在catch块中保存代码，这可以作为一种安全的选择。

为什么要捕获异常的唯一原因是要确保该块的最后一部分能够确保在已知状态下关闭/确定该异常之前启动的所有内容？但是即使那样，您仍要在执行完这些任务后引发此异常，以便全局异常处理程序通知用户，这时没有必要复制此代码吗？

这不需要捕获异常。您可以只有一个try块才有一个finally块。不需要catch块。实际上，这正是using语句实现的。如果您有在抛出异常的情况下需要清除的状态，则应实现IDisposable模式并将该对象的用法包装在using块中。

有什么简单的方法可以知道哪些模块会抛出哪些异常？我认为我已读过的唯一方法是阅读MSDN或组件供应商文档，除了无法知道要查找的特定异常(无法确定原因)之外，没有其他方法。

恰恰。但是，这并不是真正的问题，因为您只捕获了可以做些事情的异常。如果您不知道某个模块会引发特定的异常，那么显然您就不会编写处理该异常的代码。

该文档将告诉您可能需要处理的所有重要异常，例如FileNotFound，SecurityException或您所拥有的。

出现此问题是因为在我的应用程序中，我在try-catch块中有一段代码，最终导致发生异常时，这是因为对象为null或字符串无效。一旦我编写了处理这些情况的代码，就不再需要try-catch块，如果现在遇到异常，该代码将无法恢复，因此应对其进行记录并让用户知道，以便对其进行修复。

首先，避免例外始终是最好的选择。例如，如果您可以设计应用程序，使得不可能有null对象或无效字符串，那就太好了。这就是我们所谓的健壮代码。在这种情况下，您无需捕获这些异常，因为您无法处理它。您以为您已经解决了该问题，因此，无论如何，如果引发异常，则表明存在错误。不要用catch块掩盖它。

但是有时候，仍然需要catch块，您可以在catch块内编写代码来解决该问题。在这种情况下，可能没有理由重新抛出异常或将其记录下来，因此您没有任何代码重复。

但这与我一直在阅读和向我宣讲的东西背道而驰，错误的代码是没有try-catch块的代码。那么，这一切如何联系在一起，我在这里错过了什么？

完全错误。我不知道你在哪里读，但这是胡扯。例外是例外情况。如果您的代码各处都散布着catch块，则表明您做错了。您是在使用异常进行流控制，还是在误导性地吞下异常以“提高可靠性”，或者您不了解全局未处理的异常处理程序。

听起来不像我在想什么。

我不得不提到的唯一不完全符合您的任何问题的事情是，有时您可能想捕获一个异常并将其作为另一个异常重新抛出。最常见的情况是设计一个可重用的代码库。在库内部，您可能会捕获内部异常，如果无法处理它们，请将它们作为常规异常重新抛出。库的重点是封装，所以您不应让异常冒出来，以至于调用者可能无能为力。