重新抛出错误的堆栈跟踪

Question

我用“throw;”重新抛出异常，但堆栈跟踪不正确：

static void Main(string[] args) {
    try {
        try {
            throw new Exception("Test"); //Line 12
        }
        catch (Exception ex) {
            throw; //Line 15
        }
    }
    catch (Exception ex) {
        System.Diagnostics.Debug.Write(ex.ToString());
    }
    Console.ReadKey();
}

正确的堆栈跟踪应该是：

System.Exception：测试
   在 Program.cs 中的 ConsoleApplication1.Program.Main(String[] args)：第 12 行

但我得到：

System.Exception：测试
   在 Program.cs 中的 ConsoleApplication1.Program.Main(String[] args)：第 15 行

但第 15 行是“throw;”的位置。我已经用 .NET 3.5 对此进行了测试。

Answer 1

如何保留真实的堆栈跟踪？

您抛出一个新异常，并将原始异常作为内部异常包含在内。

但这很丑......更长......让你选择正确的异常抛出......

您对丑陋的看法是错误的，但对其他两点的看法是正确的。经验法则是：除非你打算用它做一些事情，比如包装它、修改它、吞下它或记录它，否则不要捕获它。如果您决定抓住然后再次抛出，请确保您正在用它做一些事情，否则就让它冒泡。

您可能还想简单地放置一个 catch，以便可以在 catch 中设置断点，但 Visual Studio 调试器有足够的选项使这种做法变得不必要，请尝试使用第一次机会异常或条件断点。

Answer 2

编辑/替换

行为实际上有所不同，但很微妙。至于为什么行为不同，我需要听从 CLR 专家的意见。

编辑：AlexD的回答< /a> 似乎表明这是设计使然。

在捕获异常的同一个方法中抛出异常会使情况有点混乱，所以让我们从另一个方法抛出异常：

class Program
{
    static void Main(string[] args)
    {
        try
        {
            Throw();
        }
        catch (Exception ex)
        {
            throw ex;
        }
    }

    public static void Throw()
    {
        int a = 0;
        int b = 10 / a;
    }
}

If throw; 时，调用堆栈为（用代码替换行号）：

at Throw():line (int b = 10 / a;)
at Main():line (throw;) // This has been modified

如果使用 throw ex;，则调用堆栈为：

at Main():line (throw ex;)

如果未捕获异常，则调用堆栈为：

at Throw():line (int b = 10 / a;)
at Main():line (Throw())

在 .NET 中测试4 / VS 2010

Answer 3

这里有一个重复的问题。

据我了解 - 扔；被编译成 'rethrow' MSIL 指令，它修改了最后一帧堆栈跟踪。

我希望它保留原始堆栈跟踪并在重新抛出的位置添加行，但显然每个方法调用只能有一个堆栈帧。

结论：避免使用 throw；并在重新抛出时将您的异常包装在一个新的异常中 - 这并不难看，这是最佳实践。

Answer 4

保留堆栈跟踪

ExceptionDispatchInfo.Capture(ex);

您可以使用以下代码示例

    static void CallAndThrow()
    {
        throw new ApplicationException("Test app ex", new Exception("Test inner ex"));
    }

    static void Main(string[] args)
    {
        try
        {
            try
            {
                try
                {
                    CallAndThrow();
                }
                catch (Exception ex)
                {
                    var dispatchException = ExceptionDispatchInfo.Capture(ex);

                    // rollback tran, etc

                    dispatchException.Throw();
                }
            }
            catch (Exception ex)
            {
                var dispatchException = ExceptionDispatchInfo.Capture(ex);

                // other rollbacks

                dispatchException.Throw();
            }
        }
        catch (Exception ex)
        {
            Console.WriteLine(ex.Message);
            Console.WriteLine(ex.InnerException.Message);
            Console.WriteLine(ex.StackTrace);
        }

        Console.ReadLine();
    }

：输出将类似于：

Test app ex
Test inner ex
   at TestApp.Program.CallAndThrow() in D:\Projects\TestApp\TestApp\Program.cs:line 19
   at TestApp.Program.Main(String[] args) in D:\Projects\TestApp\TestApp\Program.cs:line 30
--- End of stack trace from previous location where exception was thrown ---
   at System.Runtime.ExceptionServices.ExceptionDispatchInfo.Throw()
   at TestApp.Program.Main(String[] args) in D:\Projects\TestApp\TestApp\Program.cs:line 38
--- End of stack trace from previous location where exception was thrown ---
   at System.Runtime.ExceptionServices.ExceptionDispatchInfo.Throw()
   at TestApp.Program.Main(String[] args) in D:\Projects\TestApp\TestApp\Program.cs:line 47

Answer 5

好的，.NET Framework 中似乎存在一个错误，如果您抛出异常，并在同一个方法中重新抛出它，则原始行号会丢失（它将是该方法的最后一行）。

幸运的是，一个名叫 Fabrice MARGUERIE 的聪明人发现了 此错误的解决方案。下面是我的版本，您可以在 这个 .NET Fiddle 中进行测试。

private static void RethrowExceptionButPreserveStackTrace(Exception exception)
{
    System.Reflection.MethodInfo preserveStackTrace = typeof(Exception).GetMethod("InternalPreserveStackTrace",
      System.Reflection.BindingFlags.Instance | System.Reflection.BindingFlags.NonPublic);
    preserveStackTrace.Invoke(exception, null);
      throw exception;
}

现在像往常一样捕获异常，但不是抛出；只需调用此方法，瞧，原始行号将被保留！

Answer 6

不确定这是否是设计使然，但我认为一直都是这样。

如果原始的 throw new Exception 位于单独的方法中，则 throw 的结果应包含原始方法名称和行号，然后是 main 中重新抛出异常的行号。

如果您使用 throw ex，那么结果将只是 main 中重新抛出异常的行。

换句话说， throw ex 会丢失所有堆栈跟踪，而 throw 则保留堆栈跟踪历史（即较低级别方法的详细信息）。但是，如果您的异常是通过与重新抛出相同的方法生成的，那么您可能会丢失一些信息。

注意。如果您编写一个非常简单且小型的测试程序，框架有时可以进行优化并将方法更改为内联代码，这意味着结果可能与“真实”程序不同。

Answer 7

您想要正确的线路号码吗？每个方法只需使用一次 try/catch 即可。在系统中，嗯......只是在UI层，而不是在逻辑或数据访问中，这非常烦人，因为如果你需要数据库事务，那么，它们不应该在UI层，而且你不会有正确的行号，但如果您不需要它们，无论在 catch 中是否有异常，都不要重新抛出...

5 分钟示例代码：

Menu File -> 新建项目，放置三个按钮，并在每个按钮中调用以下代码：

private void button1_Click(object sender, EventArgs e)
{
    try
    {
        Class1.testWithoutTC();
    }
    catch (Exception ex)
    {
        MessageBox.Show(ex.Message + Environment.NewLine + ex.StackTrace + Environment.NewLine + Environment.NewLine + "In. Ex.: " + ex.InnerException);
    }
}

private void button2_Click(object sender, EventArgs e)
{
    try
    {
        Class1.testWithTC1();
    }
    catch (Exception ex)
    {
            MessageBox.Show(ex.Message + Environment.NewLine + ex.StackTrace + Environment.NewLine + Environment.NewLine + "In. Ex.: " + ex.InnerException);
    }
}

private void button3_Click(object sender, EventArgs e)
{
    try
    {
        Class1.testWithTC2();
    }
    catch (Exception ex)
    {
        MessageBox.Show(ex.Message + Environment.NewLine + ex.StackTrace + Environment.NewLine + Environment.NewLine + "In. Ex.: " + ex.InnerException);
    }
}

现在，创建一个新类：

class Class1
{
    public int a;
    public static void testWithoutTC()
    {
        Class1 obj = null;
        obj.a = 1;
    }
    public static void testWithTC1()
    {
        try
        {
            Class1 obj = null;
            obj.a = 1;
        }
        catch
        {
            throw;
        }
    }
    public static void testWithTC2()
    {
        try
        {
            Class1 obj = null;
            obj.a = 1;
        }
        catch (Exception ex)
        {
            throw ex;
        }
    }
}

Run...第一个按钮很漂亮！

Answer 8

我认为这不是堆栈跟踪更改的情况，更多的是与确定堆栈跟踪的行号的方式有关。在 Visual Studio 2010 中进行尝试，其行为与您在 MSDN 文档中所期望的类似：“throw ex;”从该语句“throw;”开始重建堆栈跟踪保留堆栈跟踪，除了重新抛出异常的位置之外，行号是重新抛出的位置，而不是异常所经过的调用。

所以用“投掷；”方法调用树保持不变，但行号可能会改变。

我已经遇到过几次这种情况，这可能是设计使然，只是没有完整记录。我可以理解为什么他们可能这样做，因为知道重新抛出位置非常有用，并且如果您的方法足够简单，那么原始来源通常是显而易见的。

正如许多其他人所说，通常最好不要捕获异常，除非您确实必须这样做，和/或您要在那时处理它。

有趣的旁注：Visual Studio 2010 甚至不允许我构建问题中提供的代码，因为它在编译时出现除以零错误。

Answer 9

这是因为您从第 12 行捕获了异常，并在第 15 行重新抛出了它，因此堆栈跟踪将其视为现金，即从那里抛出了Exception。

为了更好地处理异常，您应该简单地使用try...finally，并让未处理的Exception冒泡。

Answer 10

在同一个方法中抛出两次可能是一种特殊情况 - 我无法创建堆栈跟踪，其中同一方法中的不同行彼此跟随。正如该词所说，“堆栈跟踪”向您显示异常遍历的堆栈帧。而且每个方法调用只有一个堆栈帧！

如果您从另一个方法抛出，throw; 将不会按预期删除 Foo() 的条目：

  static void Main(string[] args)
  {
     try
     {
        Rethrower();
     }
     catch (Exception ex)
     {
        Console.Write(ex.ToString());
     }
     Console.ReadKey();
  }

  static void Rethrower()
  {
     try
     {
        Foo();
     }
     catch (Exception ex)
     {
        throw;
     }

  }

  static void Foo()
  {
     throw new Exception("Test"); 
  }

如果您修改 Rethrower() 并将 throw; 替换为 throw ex;，堆栈跟踪中的 Foo() 条目消失。这又是预期的行为。

Answer 11

这也算是意料之中的事情了。
修改堆栈跟踪是常见情况，如果您指定 throw ex;，FxCop 将通知您堆栈已修改。如果您进行 throw;，不会生成警告，但跟踪仍然会被修改。
所以不幸的是，现在最好不要抓住前任或将其作为内心的人扔掉。
我认为它应该被视为Windows 影响或类似的-编辑。
Jeff Richter 在他的“CLR via C#” 中更详细地描述了这种情况：

下面的代码会抛出相同的错误
它捕获的异常对象和
导致 CLR 重置其启动
例外点：

private void SomeMethod() {
  尝试 { ... }
  捕获（异常e）{
    ...
    扔 e； // CLR 认为这是异常产生的地方。
    // FxCop 将此报告为错误
  }
}

相反，如果你重新抛出一个
使用 throw 抛出异常对象
关键字本身，CLR 不会
重置堆栈的起点。这
以下代码重新抛出相同的错误
它捕获的异常对象，
导致 CLR 不重置其
异常的起始点：

private void SomeMethod() {
  尝试 { ... }
  捕获（异常e）{
    ...
    扔; // 这对 CLR 认为异常的位置没有影响
    //起源。 FxCop 不会将此报告为错误
  }
}

事实上，唯一的区别是
这两个代码片段是什么
CLR认为是原来的位置
抛出异常的地方。
不幸的是，当你扔或
重新抛出异常，Windows 会这样做
重置堆栈的起点。所以
如果异常未处理，
报告的堆栈位置
Windows 错误报告是
最后一次投掷的位置或
重新抛出，即使 CLR 知道
原来的堆栈位置
抛出异常。这是
不幸的是，因为它使得调试
失败的应用程序
场要困难得多。一些
开发人员发现了这一点
无法忍受他们选择了
不同的方式来实现他们的代码
以确保堆栈跟踪真实
反映了一个位置
最初抛出异常：

private void SomeMethod() {
  布尔值 trySucceeds = false;
  尝试 {
    ...
    尝试成功 = true;
  }
  最后 {
    if (!trySucceeds) { /* catch 代码放在这里 */ }
  }
}

Answer 12

这是 Windows 版本的 CLR 中众所周知的限制。它使用 Windows 内置的异常处理 (SEH) 支持。问题是，它是基于堆栈帧的，并且一种方法只有一个堆栈帧。您可以通过将内部 try/catch 块移动到另一个辅助方法中来轻松解决该问题，从而创建另一个堆栈帧。此限制的另一个后果是 JIT 编译器不会内联任何包含 try 语句的方法。