Wrong line number on stack trace

by

Yes, this is a limitation in the exception handling logic. If a method contains more than one throw statement that throws an exception then you’ll get the line number of the last one that threw. This example code reproduces this behavior:

using System;

class Program {
    static void Main(string[] args) {
        try {
            Test();
        }
        catch (Exception ex) {
            Console.WriteLine(ex.ToString());
        }
        Console.ReadLine();
    }
    static void Test() {
        try {
            throw new Exception();  // Line 15
        }
        catch {
            throw;                  // Line 18
        }
    }
}

Output:

System.Exception: Exception of type 'System.Exception' was thrown.
   at Program.Test() in ConsoleApplication1\Program.cs:line 18
   at Program.Main(String[] args) in ConsoleApplication1\Program.cs:line 6

The work-around is simple, just use a helper method to run the code that might throw an exception.

Like this:

static void Test() {
    try {
        Test2();                // Line 15
    }
    catch {
        throw;                  // Line 18
    }
}
static void Test2() {
    throw new Exception();      // Line 22
}

The underlying reason for this awkward behavior is that .NET exception handling is built on top of the operating system support for exceptions. Called SEH, Structured Exception Handling in Windows. Which is stack-frame based, there can only be one active exception per stack frame. A .NET method has one stack frame, regardless of the number of scope blocks inside the method. By using the helper method, you automatically get another stack frame that can track its own exception. The jitter also automatically suppresses the inlining optimization when a method contains a throw statement so there is no need to explicitly use the [MethodImpl] attribute.

More Related Contents:

  1. Why catch and rethrow an exception in C#?
  2. Will code in a Finally statement fire if I return a value in a Try block?
  3. Main method code entirely inside try/catch: Is it bad practice?
  4. Why is try {…} finally {…} good; try {…} catch{} bad?
  5. When to use try/catch blocks?
  6. How to keep running a program if an exception occurs? [duplicate]
  7. Is there a difference between “throw” and “throw ex”?
  8. WPF global exception handler [duplicate]
  9. Best practices for catching and re-throwing .NET exceptions
  10. Catch an exception thrown by an async void method
  11. Globally catch exceptions in a WPF application?
  12. catch exception that is thrown in different thread
  13. Does the C# “finally” block ALWAYS execute? [duplicate]
  14. .NET Global exception handler in console application
  15. Is there a reason Image.FromFile throws an OutOfMemoryException for an invalid image format?
  16. C++, __try and try/catch/finally
  17. Why use finally in C#?
  18. catch exception by pointer in C++
  19. What’s the difference between Application.ThreadException and AppDomain.CurrentDomain.UnhandledException?
  20. What is the real overhead of try/catch in C#?
  21. Handling exceptions, is this a good way?
  22. File access error with FileSystemWatcher when multiple files are added to a directory
  23. Are destructors called after a throw in C++?
  24. How to catch ALL exceptions/crashes in a .NET app [duplicate]
  25. Is this a bad practice to catch a non-specific exception such as System.Exception? Why?
  26. What is ApplicationException for in .NET?
  27. Show line number in exception handling
  28. Getting Cross-thread operation not valid [duplicate]
  29. Is it “bad” to use try-catch for flow control in .NET?
  30. How to log all thrown exceptions?

Leave a Comment