Proposal: Custom names for lambdas in Stacktraces

[gravityFlower]

Custom names for lambdas in Stacktraces

Summary

Attribute [StacktraceName] to provide custom names for lambdas.

Motivation

When trying to find the cause of bugs, it's sometimes hard to follow the Stacktrace due to the anonymous names of lambdas.

Example:

   at UserQuery.<>c.<Main>b__4_2(Int32 i), line 5
   at System.Linq.Enumerable.WhereEnumerableIterator`1.MoveNext()
   at System.Linq.Enumerable.TryGetFirst[TSource](IEnumerable`1 source, Boolean& found)
   at System.Linq.Enumerable.First[TSource](IEnumerable`1 source)
   at UserQuery.<>c.<Main>b__4_0(IEnumerable`1 ienum), line 5
   at UserQuery.Test.GetNumber(IEnumerable`1 ienumerable, Func`2 predicate), line 12
   at UserQuery.Main(), line 5

Since lambdas are compiled to anonymous functions in anonymous classes, the StacktraceNameAttribute would allow it to trace the origin of the code more easily in case of lambdas.

Detailed design

Used in code it would look something like this:

void Main()
{
	new Test().GetNumber(new[] { 4, 1, 3, 2, 5 },  ienum => ienum.OrderBy(i => i).Where([StacktraceName("GetNumberLambdaWhereCondition")]i => i != 2 ? throw new Exception("Stacktrace") : true).First());
}

class Test
{	
	public int GetNumber(IEnumerable<int> ienumerable, Func<IEnumerable<int>, int> predicate)
	{
		return predicate(ienumerable);
	}	
}

resulting in a Stacktrace where the anonymous name is replaced with the provided one

   at UserQuery.<>c.<Main>GetNumberLambdaWhereCondition(Int32 i), line 5
   at System.Linq.Enumerable.WhereEnumerableIterator`1.MoveNext()
   at System.Linq.Enumerable.TryGetFirst[TSource](IEnumerable`1 source, Boolean& found)
   at System.Linq.Enumerable.First[TSource](IEnumerable`1 source)
   at UserQuery.<>c.<Main>b__4_0(IEnumerable`1 ienum), line 5
   at UserQuery.Test.GetNumber(IEnumerable`1 ienumerable, Func`2 predicate), line 12
   at UserQuery.Main(), line 5

or completely replacing the anonymous class and method name and instead using the custom provided named with a hint like

   at UserQuery.<Lambda>GetNumberLambdaWhereCondition(Int32 i), line 5
   at System.Linq.Enumerable.WhereEnumerableIterator`1.MoveNext()
   at System.Linq.Enumerable.TryGetFirst[TSource](IEnumerable`1 source, Boolean& found)
   at System.Linq.Enumerable.First[TSource](IEnumerable`1 source)
   at UserQuery.<>c.<Main>b__4_0(IEnumerable`1 ienum), line 5
   at UserQuery.Test.GetNumber(IEnumerable`1 ienumerable, Func`2 predicate), line 12
   at UserQuery.Main(), line 5

Drawbacks

Currently not known.

Alternatives

Open for suggestions.

[YairHalberstadt]

If you need a name, you could use a local function.

Currently attributes are forbidden on expressions, and can only be applied to members, so this is a huge change. There would have to be a far bigger use case (which there are BTW) to justify making that change.

[djblack]

It would be easier if the compiler generated a more descriptive name or attribute and attached it to the anon class/method. Which the debugger then displays.

[YairHalberstadt]

@djblack
How should the descriptive name be generated? If you have any ideas which are cheap, both in terms of implementation and performance, the developers at Roslyn may be interested.

[djblack]

@djblack
How should the descriptive name be generated? If you have any ideas which are cheap, both in terms of implementation and performance, the developers at Roslyn may be interested.

Well the most obvious description would be the contents of the lambda, or if it is too long the start of it. I guess this would have to be stored in an attribute though.

[qrli]

I also would like the stack trace could be more readable, but I don't want to name it manually.

I think the compiler can be smarter to find the receiving variable name or parameter name, and use that to compose a readable lambda name. It does not need to be perfect or 100% accurate, as this is only for debugging and we can figure out which is which.

[TonyValenti]

It would be great if it showed the expression (or at least the first line of it). For example
x => x.Age > 21

[CyrusNajmabadi]

This doesn't feel like a language request at all, but rather a debugger enhancement.

[CyrusNajmabadi]

at UserQuery.<>c.<Main>b__4_2(Int32 i), line 5

Debugger should be able to see that that's some mangled name and, using the pdb information, map that back to some piece of source. that source can then be used to try to give a better name/text piece there.

[qrli]

@CyrusNajmabadi It is not always with debugger and pdb. A common case is to investigate logs of production server, e.g. with Application Insights. It is good enough to provide all the related request chain and exception details. But that's all info I can get.

Yes, I can save a minidump with the log, and then load it in visual studio, and then find the correct pdb files corresponding to the app version in production, so that the debugger can help me to decipher the name. But, 98% of the cases, I don't bother to go this far. Usually, the bug can be identified just by looking at the exception message and call stack, while reading the function source code, as long as the function is not very long.

[CyrusNajmabadi]

A common case is to investigate logs of production server, e.g. with Application Insights.

Again, taht seems like a tooling issue. What can the language do here? Even if the compiler were to, say, emit some sort of special attribute (again, not a language issue), it would be up to the tooling to understand that.

A stack trace has nothing to do with the language. it's an entirely a tooling choice as to how the runtime and associated tools do things.

[qrli]

Again, taht seems like a tooling issue. What can the language do here?

The compiler actually generates a function and the name is given by the compiler, while all tooling just uses that name by default. Rather than something like <Main>b__4_2, it will be better to include the receiving variable name or parameter name in the auto-generated name, e.g. <Main>b__4_2__predicate, which would be much more recognizable.

Not all tooling can easily access source code and pdb. And this is not a corner case. Golang solves it by including necessary necessary pdb info into the final binary, which looks over-killing to me. But it is good that they tried to make it better.

[CyrusNajmabadi]

The compiler actually generates a function and the name is given by the compiler,

You mentioned the compiler twice. As i asked: What can the language do here?

I'm pointing this out because this issue is currently under dotnet/csharplang. However, it seems like you're asking for a tooling change in the compiler.

Rather than something like

b__4_2, it will be better to include the receiving variable name or parameter name in the auto-generated name, e.g. b__4_2__predicate, which would be much more recognizable.

That would be a tooling change request. That should go in dotnet/roslyn, not dotnet/csharplang.

[qrli]

That's true. Sorry I missed that point.