异常处理中的异常处理

Question

异常处理中的异常处理的最佳做法是什么？

我发现自己正在使用现有的C＃（Framework 4.0）系统，该系统在catch中使用自定义对象，最后在系统的大多数Application Server层中进行阻塞。

考虑以下代码库中方法的剪切版本：

    public void DoSomeStuff(string sGUID)
    {
        try
        {
            // Foo
        }
        catch (Exception oEx)
        {
            oExceptions.Add(oEx);

            if (oDBConn.NumberOfActiveTrans > 0)
            {
                oDBConn.Rollback();
            }
        }
        finally
        {
            oDBConn.DeleteLocksByGUID(sGUID);
        }
    }

我可能过于偏执，但我发现自己非常担心这些可能发生的未处理的异常。

因此，像以下更新版本这样的东西是可接受的做法还是有更好的方法来完成同样的事情？

    public void DoSomeStuff(string sGUID)
    {
        try
        {
            // Foo
        }
        catch (Exception oEx)
        {
            oExceptions.Add(oEx);

            try
            {
                if (oDBConn.NumberOfActiveTrans > 0)
                {
                    oDBConn.Rollback();
                }
            }
            catch (Exception oEEx)
            {
                oExceptions.Add(oEEx);
            }
        }
        finally
        {
            try
            {
                oDBConn.DeleteLocksByGUID(sGUID);
            }
            catch (Exception oFEx)
            {
                oExceptions.Add(oFEx);
            }
        }
    }

Answer 1

我个人不会在try catch中添加finally块，然后它可能是一个无穷无尽的链。通常你不应该在finally中有复杂的东西，并且在任何情况下都应该在调用者中捕获意外的异常。

编辑：看起来更接近代码，我不明白为什么finally中的代码不应该在try块中。

Answer 2

  

我可能过于偏执，但我发现自己非常担心   这些可能发生的未处理的异常。

不要惊慌。如果db层中有错误，请尝试捕获它。

Answer 3

原始代码中最危险的事情是，如果和失败，事务回滚失败，唯一的错误重新抛出将是回滚事务的错误。您永远不会知道导致您必须回滚事务的原始异常是什么。那是你最关心的那个。

如果您想要偏执，请记录事务回滚的失败。但重要的是之前的异常让你达到了这一点。应根据调用者的期望记录或重新编译。