嵌套Try/Catch

Question

嵌套的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方法中我重新抛出,所以我可以在上面的代码中在更高级别捕获它.但是,如果我再次在捕获物内投掷,那么我也需要抓住它.

Answer 1

以下是我们解决问题的方法:

从UI /代码隐藏级别到其他层的所有调用都使用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.IMO这是个人选择.我们认为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;
        }
    }
}

最后,作为故障安全,我们实现了Application_Error全局事件处理程序(in Global.asax).对于我们没有正确尝试捕捉某些东西的情况,这是最后的手段.我们通常会记录并重定向到友好的错误页面.如果上面的自定义错误处理成功完成,很少有错误会使它成为全局处理程序.

希望这可能会有所帮助.这是一种可能的解决方案.几年来,它在一些较大的应用中对我们非常有效.

Answer 2

嵌套try/catch块在顶级应用程序中是不可避免的,这些应用程序需要以其他非平凡的方式记录,发送消息或对异常做出反应.

有一些方法可以减少嵌套块的数量(例如,使用ASP.NET的HttpApplication.Error处理程序(aka Application_Error)整合错误处理),但是您应该捕获处理代码产生的任何异常,并在其他所有方法都失败的情况下实施备份计划.