Using a lambda expression versus a private method

Question

I read an answer to a question on Stack Overflow that contained the following suggested code:

Action logAndEat = ex => 
{  
    // Log Error          


        

Answer 1

LogAndEat can reference private fields within the function where it's defined. So:

private bool caughtException; 

Action<Exception> logAndEat = ex => 
    {  
        caughtException = true;
    };

try
{
    // Call to a WebService
}
catch (SoapException ex)
{
    logAndEat(ex);
}
catch (HttpException ex)
{
    logAndEat(ex);
}
catch (WebException ex)
{
    logAndEat(ex);
}

if (caughtException)
{
    Console.Writeline("Ma, I caught an exception!");
}

This is a trite example (!) but this potentially can be a lot tidier than passing a bunch of parameters through to a private method.

Answer 2

I guess you could think of the lambda expression in this example as being a little bit like Pascal's nested functions, in that it's code that can only be executed by the method it's declared in.

A private method could be called from any method in the same class, while a lambda like this is local to the current method and is therefore explicitly only used in that context.

That's really the only advantage I can think of - being explicit in terms of expected usage.

Answer 3

To understand whether it's better to use a lambda expression (as I did in the original answer) or use a 'proper' method, we need to make a decision based on how reusable the common error handling code is.

• If the common error handling code is completely reusable by other functions in different classes across the application, then it should probably be an internal or public function, which may be in a different class if that makes the code organisation more sensible.

• If the common error handling code is reusable by other function in the same class only, then it should probably be a private function in the same class.

• If the common error handling code is not reusable by any other function, and should only ever be used by this particular function, then you have two choices. The first is to use a delegate to encapsulate it within the boundaries of the function, ensuring that the function does not leak any implementation details. The second is to use a private function in the same class with a comment that it should only be called by the function it is intended for.

In the third case, there is no clear 'best way' to do it as both are perfectly legitimate ways to achieve the same goal. My tendency would be to use a delegate when the common code is small and/or you need some of the behaviour of delegates like capturing variables.

Now, coming back to the question, why I wrote the code using a delegate? I had no information about whether the error handling code was re-usable, so I assumed that it was not, and decided to use a delegate as I figured people would find it easy to go from this to realising it could be a 'proper' method (as you have) whereas if I showed use of a 'proper' function people may not realise that a delegate would be an alternative.

Answer 4

IMO I don't like tiny little private functions that are only used in another private method wondering around my classes I just find them ugly, that's why I'd use the lambda in that sample

I don't think there's gonna be a performance impact in using the lambda instead of a function

Answer 5

A lot comes down to personal preference, nobody can say one absolute way is the right way or the wrong way.

Lambda Expressions behave like closures in other languages, the cool thing about them is that they can access variables scoped to the method they're declared in. This adds a lot of flexibility to what you can do in your code, but comes at a cost of not being able to modify code in that method while debugging.

For that reason, if you're going to be logging errors, you might find yourself in a debugger in that method at some time or another. If you use a lambda, you won't be able to modify any code at runtime - so for this reason my preference would be to use a separate private method that accepts the exception as its parameter.

Answer 6

Variables captured by logAndEat would otherwise be parameters to the LogAndEat method. You could consider it a form of currying.