异常处理中的异常处理

Question

异常处理中的异常处理最佳实践是什么？

我发现自己正在开发一个现有的C# (Framework4.0)系统，该系统在catch中使用自定义对象，并最终阻塞整个系统的大多数Application层。

考虑一下这个代码库中的一个方法的以下片段版本：

    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中包含复杂的内容，而且在任何情况下，调用方都应该捕捉到意外的异常。

编辑:仔细看一下代码，我不明白为什么最终的代码不应该在try块中。

Answer 2

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

别惊慌。如果db层中有错误，尝试在那里捕获它。

Answer 3

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

如果您想疑神疑鬼，请记录事务回滚失败。但重要的是之前的例外让你到了那个地步。应该根据调用者的期望记录或重新抛出。