D
Daniel O'Connell [C# MVP]
I bet most of you are already prepared to give the stock StackFrame answer,
however that isn't what I'm asking.
I'm mostly thinking aloud here, but with the limitations of StackFrame, most
specifically that it gets line and file information from debug symbols, does
anyone think there would be value(or more specifically, value worth the
language complexity) to adding such a feature as C\C++'s __LINE__ macro to
the language?
I really have two reasons why I am currently leaning towards thinking they
would come in handy. The first and formost one in my mind is that I find it
to be egregious to have to create an object and call a method to determine
something the compiler could easily provide as an intrinsic literal.
Secondly, and perhaps more importanty, maintaining line, file, etc
information for traces by hand is pretty much impossible. So you can often
use StackFrame to ease up on this while debugging. But, when you build the
app in release mode, the loss of functionality in StackFrame is sufficent to
make locating a specific trace message\exception source a minor chore.
However, with the advent of several features in C# 2.0(partial classes, anon
methods, and iterators), I fear that a stack trace without line information
will be just this side of useless in many situations. Imagine a stack trace
akin to:
at StackTraceTest.Class1.__AnonymousMethod$0000()
at StackTraceTest.Class3.OnEventX()
at StackTraceTest.Class1.__AnonymousMethod$0001()
at AnotherTest.Class2.__AnonymousMethod$0001()
at StackTraceTest.Class1.DoWork()
at StackTraceTest.Class1.Main(String[] args)
Its not pretty and you have no idea how you really got to OnEventX(). (on
another note, this is reason enough to argue that an anonymous method's name
should contain the containing method name, if applicable,
__AnonymousMethod$0001 doesn't tell you much, __AnonymousMethod_DoWork$0001,
on the other hand would tell you where that method was defined, making it
far more identifiable).
Anyway, does anyone have any other thoughts on the issue? Reasons for or
against such compiler intrinsics?
however that isn't what I'm asking.
I'm mostly thinking aloud here, but with the limitations of StackFrame, most
specifically that it gets line and file information from debug symbols, does
anyone think there would be value(or more specifically, value worth the
language complexity) to adding such a feature as C\C++'s __LINE__ macro to
the language?
I really have two reasons why I am currently leaning towards thinking they
would come in handy. The first and formost one in my mind is that I find it
to be egregious to have to create an object and call a method to determine
something the compiler could easily provide as an intrinsic literal.
Secondly, and perhaps more importanty, maintaining line, file, etc
information for traces by hand is pretty much impossible. So you can often
use StackFrame to ease up on this while debugging. But, when you build the
app in release mode, the loss of functionality in StackFrame is sufficent to
make locating a specific trace message\exception source a minor chore.
However, with the advent of several features in C# 2.0(partial classes, anon
methods, and iterators), I fear that a stack trace without line information
will be just this side of useless in many situations. Imagine a stack trace
akin to:
at StackTraceTest.Class1.__AnonymousMethod$0000()
at StackTraceTest.Class3.OnEventX()
at StackTraceTest.Class1.__AnonymousMethod$0001()
at AnotherTest.Class2.__AnonymousMethod$0001()
at StackTraceTest.Class1.DoWork()
at StackTraceTest.Class1.Main(String[] args)
Its not pretty and you have no idea how you really got to OnEventX(). (on
another note, this is reason enough to argue that an anonymous method's name
should contain the containing method name, if applicable,
__AnonymousMethod$0001 doesn't tell you much, __AnonymousMethod_DoWork$0001,
on the other hand would tell you where that method was defined, making it
far more identifiable).
Anyway, does anyone have any other thoughts on the issue? Reasons for or
against such compiler intrinsics?