问嵌套的Try/Catch
EN

Stack Overflow用户

提问于 2010-02-22 19:54:35

回答 5查看 8.3K关注 0票数 18

使用嵌套的Try/Catch是不是编码不干净的信号？我想知道是不是因为在catch中我调用了另一个方法，如果调用失败，我会得到另一个运行时错误，所以我很想再次使用try/catch将这些调用包装在catch中。我想知道这样做是否正常？

例如：

    catch (Exception ex)
    {
        transaction.VoidOrder(transactionID);

        LogError(ex.ToString());
        Response.Redirect("Checkout", false);
    }

因此，VoidOrder甚至LogError方法可能会崩溃。现在，当我调用VoidOrder时，我在transactionID上得到了一个空引用，因为它调用了BL方法，在BL方法中，我重新抛出了它，这样我就可以在上面代码的更高级别捕获它。但是如果我在接球内再次投球，那么我也需要接球。

nested

try-catch

回答 5

Stack Overflow用户

发布于 2010-02-22 20:00:31

下面是我们解决这个问题的方法：

从UI/ catch后台级别到其他层的所有调用都使用try-catch，其中我们总是捕获自定义异常。底层采取的所有操作都有自己的try-catch，用于记录、包装和抛出自定义异常。然后，UI可以依赖于此，并查找具有友好错误消息的已处理异常。

代码背后：

protected void btnSubmit_Click(object sender, EventArgs e)
{
    //do something when a button is clicked...
    try
    {
        MyBL.TakeAction()
    }
    catch(MyApplicationCustomException ex)
    {
        //display something to the user, etc.
        ltlErrorPane.Text = ex.Message;

        //or redirect if desired
        if(ex.ErrorType == MyCustomErrorsType.Transactional)
        {
            Response.Redirect("~/Errors/Transaction.aspx");
        }
    }
}

BL:

在业务层中，任何可能失败的操作都会使用try-catch，它会在将问题抛到UI之前记录并包装问题。

public class MyBL
{
    public static void TakeAction()
    {
        try
        {
            //do something
        }
        catch(SpecificDotNetException ex)
        {
            //log, wrap and throw
            MyExceptionManagement.LogException(ex)
            throw new MyApplicationCustomException(ex, "Some friendly error message", MyCustomErrorsType.Transactional);
        }
        finally
        {
            //clean up...
        }
    }
}

异常处理程序：

实际的异常处理程序有多种方式来记录日志，包括事件日志、文件日志，如果所有其他方法都失败了，最后还会发送电子邮件。如果记录器不能执行任何预期的操作，我们选择简单地返回false。不过，这是我个人的选择。我们认为3种方法连续失败的可能性很小(事件日志失败，尝试文件日志失败，尝试电子邮件失败，失败)。在这种情况下，我们选择允许应用程序继续运行。你的另一个选择是让应用程序完全失败。

public static class MyExceptionManagement
{
    public static bool LogException(Exception ex)
    {
        try
        {
            //try logging to a log source by priority, 
            //if it fails with all sources, return false as a last resort
            //we choose not to let logging issues interfere with user experience

            //if logging worked
            return true;
        }
        catch(Exception ex)
        {
            //in most cases, using try-catch as a true-false is bad practice
            //but when logging an exception causes an exception itself, we do
            //use this as a well-considered choice.
            return false;
        }
    }
}