[Mono-dev] Mono/.NET Framework Very Different Stack Traces

[Bryan Murphy]

I have a very simple test program:

01 using System;
02
03 public static class Program {
04    public static void ThrowCatchRethrow() {
05        try {
06            throw new InvalidOperationException();
07        } catch (Exception) {
08            throw;
09        }
10    }
11
12    public static void Main(string[] args) {
13        try {
14            ThrowCatchRethrow();
15        } catch (Exception ex) {
16            Console.Error.WriteLine(ex);
17        }
18    }
19 }


I compile this using the following:

$ gmcs -debug -out:ExceptionTest.exe ExceptionTest.cs
$ csc.exe /debug /out:ExceptionTest.exe ExceptionTest.cs

When I execute it under the .NET framework, I get the following stack trace:

$ ./ExceptionTest.exe
System.InvalidOperationException: Operation is not valid due to the current
state of the object.
   at Program.ThrowCatchRethrow() in
u:\Workspace\MonoTest\ExceptionTest.cs:line 8
   at Program.Main(String[] args) in
u:\Workspace\MonoTest\ExceptionTest.cs:line 14

When I execute it under Mono, I get the following:

$ mono --debug ./ExceptionTest.exe
System.InvalidOperationException: Operation is not valid due to the current
state of the object
  at Program.ThrowCatchRethrow () [0x00000] in
U:\Workspace\MonoTest\ExceptionTest.cs:6

Here you can clearly see that the stack traces are *very* different.  In
fact, while it's nice that Mono shows line #06 as the place where the
exception is actually thrown, it loses the fact that line #14 was also part
of the stack at the time of the error.

The .NET framework shows line #08 as the place where the exception was
thrown, which is not ideal, however it includes line #14 which is what I
really want.

Is there a way we can get the stack traces to look more like the .NET
framework stack traces?  I actually find it significantly easier to track
down the location of a problem when presented with the .NET stack trace.

I know I can wrap and rethrow, but that loses the type of the initial
exception so it's not a feasible solution.  We're going to add a centralized
logging service and audit our code to try and track down these issues,
however, that's a rather painful way to go about this and we keep running
into this problem again and again.

Thanks,
Bryan
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.ximian.com/pipermail/mono-devel-list/attachments/20101214/65b7ad39/attachment.html