Question

如果我有这样的代码：

void a()
{
    try
    {
        b();
    }
    catch (MyException)
    {
        // Handle any problems that occurred in b(c(d()))
    }
}

void b()
{
    c();
    // Do something else
}

void c()
{
    d();
    // Do something else
}

void d()
{
    // Do something, throw a MyException if it fails
}

假设在任何时候都不需要清理，最好在c（）中调用d（）和调用b（）中的c（）或者调用try {} catch {throw;}它认为可以让d（）的异常在没有任何介入的try / catch块的情况下自然地冒泡到a（）“

我认为额外的try / catch块可以作为一种“文档”，但它们似乎是多余的，所以我只是想知道其他人会认为最好的方式。

很抱歉，如果这有点太基础了，我正试图了解异常，但我似乎对它们没有好感。

Answer 1

让它传播直到你能够处理它。如果你无法处理它，就没有必要抓住它。所以问题是，你能否有效地处理c()方法中的异常？

Answer 2

基本上没有。这不是处理这些情况的建议方法。

当且仅当您可以处理它们并执行适当的操作或向调用堆栈中较高的调用方提供更多信息时（通过将其封装在更通用的异常中），您应该捕获异常。如果你不能这样做，你应该让异常在调用堆栈中冒泡，直到有人能够正确处理它。

Answer 3

例外的巨大优势在于，您可以处理可以对其进行操作的问题，而不是直接处理其中的问题。检测到丢失的文件，或者在函数的调用者或其调用者中检测到，＆amp; c。

但是，的例外也可以在链的某处处理。这些点出现的位置取决于您使用的框架，以及它的异常管理所包含的内容。关键问题是：你的进入点是什么允许异常逃脱未被捕获会产生不良影响？典型的例子包括

交互式UI应用程序中的事件处理代码（至少在WinForms和ASP.NET中可以通过提供exception event handlers来集中捕获）。
您响应外部邮件的集成点（例如，从队列中获取邮件，处理文件，侦听命名管道，实施WCF服务）。
进行后台处理的计时器事件。
线程启动方法。

有时，您还希望捕获一个低级别的常规技术错误，并将其重新抛出为更具特定领域的异常。这通常在设计良好的库中完成，以保护用户免受其内部实现细节的影响。在企业应用程序中，您可能希望捕获某些SqlExceptions并将其重新抛出为特定于应用程序的异常（例如YourApp.UnknownCustomer），以便在更高级别的逻辑上处理它们。

我的建议是：尽可能处理最高级别的问题，但要确保异常捕获有合理的例外情况可以使用。顺便说一句，除非你讨厌你的用户，否则不要向他们显示异常及其堆栈跟踪！ ; - ）

Answer 4

我会说，这取决于你想对这些信息做些什么。

我总是试图尽可能地接近源代码来解决问题 - 为什么要一直运行问题，而不是试图在它发生的地方处理它？为了便于阅读和理解代码，我也相信try / catch尽可能接近问题的根源。

如果您正在为自己编写程序，并且没有其他任何人可以触摸它，请做任何最适合您和代码的程序。

捕获最佳实践的异常（c＃/ .net）

4 个答案: