异常处理中的异常处理

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

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

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

Answer 2

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

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

Answer 3

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

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