This project is read-only.

Custom name for anonymous methods and lambda expressions to have more readable stack traces.


As you may already know, we can assign a name to a function in javascript, see a following sample:
jQuery.ajax("some url : jQuery.ajax will get something from a specified web resource").then(function yourCustomNameForCallBackFunction(){ /* do something in your custom callback function after getting content from web resource is finished. Your callback will be called by jQuery itself. */ });
That callback function acts as a lambda expression or anonymous method passed into the method which accepts delegate in C#. (I know there are several differences, and I'm aware of Expression trees etc ...).

When any exception raises in your function, you'll have a stack trace as like as:

Uncaught !
(program):2 yourCustomNameForCallBackFunction

"yourCustomNameForCallBackFunction" is a name of your callback function, and you've a readable stack trace here.

But, because there is no such ability in C#, I get following stacktrace
Unhandled exception .... at b__0() ...

I'd like to give a name to a method that will be created later with magics of C# compiler to improve readability of my exceptions' stack traces.

Sample desired code:
public static class OperationsManager
    public static void DoSomeThing(Action doAfterThat)
         // do something ....
         if(doAfterThat != null)

Usage: OperationsManager.DoSomeThing(() => myCustomName { /* do something after that */ });

Usage with named parameters: OperationsManager.DoSomeThing(doAfterThat : () => myCustomName { /* do something after that */ });


PauloMorgado wrote Jan 17, 2015 at 11:42 PM

How do you propose it to work with something like this?
var s = "test";
Func<string> l = () => s;

real_persian wrote Jan 18, 2015 at 2:39 AM

Thanks for your participating
The simplified syntax of writing lambda expressions has more limitation than the full syntax one, for example it can not contains more than one CSharp statement.
I know that this syntax is widely used, specially in linq queries, and it's a only way construct and pass a variable as a parameter to a method which accept Expression<Func<T>> for example, but I simply say, we can ignore it.
It can have another limitation in comparison with full syntax one.

VSadov wrote Jan 19, 2015 at 6:52 PM

"named lambdas" feature is not as simple as it may look if you look deeper. Once you start name things, you need to resolve issues related to what names are considered wellformed, within what scopes names must be unique and how that is enforced.
I.E. - what kind of strings are valid lambda names? Is it ok to have lambdas named the same within the same block/method/type?