Don't mix using statements and lambda expressions

a-foton » Don’t mix using statements and lambda expressions

a-foton » Don’t mix using statements and lambda expressions — Wed, 16 Jul 2008 15:34:39 GMT

PingBack from http://blog.a-foton.ru/2008/07/dont-mix-using-statements-and-lambda-expressions/

Don't Mix Lambda Expressions and Using Statements

Jesse Ezell Blog — Wed, 16 Jul 2008 15:48:00 GMT

Lambda expressions are really cool, but they present some interesting problems because they aren't really

re: Don't mix using statements and lambda expressions

Joe Enos — Thu, 17 Jul 2008 00:21:42 GMT

Never would have thought of that one...Thanks.

re: Don't mix using statements and lambda expressions

zproxy — Thu, 17 Jul 2008 10:09:54 GMT

The program does what you say it should to. It looks like the programmer clearly does not understand when is what executed. By simply moving the using statement inside the delegate it will be fixed...

re: Don't mix using statements and lambda expressions

Eddie Garmon — Thu, 17 Jul 2008 17:42:57 GMT

You need to clarify your blanket rule. It is perfectly fine to use lambdas inside a using block. I believe what you meant to say is: Don’t take any lifetime dependencies upon the object being 'used', and return that object as a lifted variable in a lambda function.

Below is a contrived but perfectly valid example of a lambda inside a using.

static void Example() {

int[] numbers = { 1, 2, 3, 4, 5 };

using (var obj = new MyDisosableObject()) {

numbers.ForEach(i => Console.WriteLine("{0} squared is {1}", i, i * i));

}

Weekly Web Nuggets #21

Code Monkey Labs — Mon, 21 Jul 2008 03:25:41 GMT

General Lessons That I Learned From Waegis : Keyvan Nayyeri shares the lessons he learned from launching Waegis , a spam filter for web sites. Don't Mix Using Statements And Lambda Expressions : Jared Parsons explains why you do not want to mix using

re: Don't mix using statements and lambda expressions

Jared Parsons — Tue, 22 Jul 2008 19:13:17 GMT

@Eddie,

There are definately cases where this is valid and useful. The issue I was refering to can be better summed up as "Don't use lamda expressions which do both of the following"

1) Lambda extends the lifetime of a lifted variable beyond the current function

2) Lifted variable is iteration or using variable.

There are probably other cases in #2 that I'm missing.

In general though I think it's better to have a more encompasing rule which disallows certain valid cases than a rule which is less encompassing and allows invalid cases. I'm a bit paranoid though and I've been bitten by the iteration variable before so I tend to be picky about this.

re: Don't mix using statements and lambda expressions

Eddie Garmon — Tue, 22 Jul 2008 20:57:58 GMT

Ok, I do agree with the above. I had to go back and revalidate my Synchronized<T> as you made me think, (which is the point of this right?) as I do both of the above, but not at the same time.

Syntactic Sugar at work

Ted — Tue, 22 Jul 2008 21:30:49 GMT

Lambda expressions appear to be just syntactic sugar apart from querying a SQL server database.

re: Don't mix using statements and lambda expressions

Orlando — Mon, 11 Aug 2008 19:10:53 GMT

Jared I must say this is strange behavior. Shouldn't the using statement be able to override the scope extension of the lambda expression instead of allowing this inconsistent behavior?

re: Don't mix using statements and lambda expressions

Jared Parsons — Mon, 11 Aug 2008 19:41:22 GMT

@Orlando,

I think you mean issue a compiler error because of the scope change. If so in an ideal world this should be the case. However it is not done at this time for a couple of reasons.

The first is cost. For the compiler to accurately spot this as an error it must determine that the lambda will actually live beyond the scope of the current function. This is very expensive (if not impossible). In this case the compiler would have to dig into the IL of every function the lambda was either passed to or called. The analysis would include deep flow analysis to determine if the lambda was ever stored in a place that was eventually returned from the function or passed to a different thread or even to PInvoke. This is very costly in both man hours to implement and compile time.

The other is correctness. Even though it's against design guidlines, there is nothing stopping you from using an object once it's been disposed. You can in fact (please don't though) design an object to have a subset of it's properties/methods be valid after it's disposed. In this case the code I laid out would still be correct so the compiler would be issuing a false warning.

re: Don't mix using statements and lambda expressions

Kyle Sluder — Tue, 12 Aug 2008 02:39:31 GMT

I think it makes sense to do this:

func<IDisposable, string> f = x => { using(x) { x.ToString() } };

This certainly can't be a universally Bad Idea(TM), can it?

re: Don't mix using statements and lambda expressions

James Hart — Tue, 12 Aug 2008 19:17:45 GMT

LINQ expressions also introduce lambdas, less explicitly, and are particularly vulnerable to this sort of thing.

IEnumerable<string> Names

{

get {

using (var conn = new SqlConnection(ConnectionString))

using (var cmd = new SqlCommand("SELECT Name FROM People", conn))

{

conn.Open();

return

from row in cmd.ExecuteReader().Cast<IDataRecord>()

select row["Name"] as string;

}

But then again, the same problem occurs if you just do this:

SqlDataReader Names

{

get {

using (var conn = new SqlConnection(ConnectionString))

using (var cmd = new SqlCommand("SELECT Name FROM People", conn))

{

conn.Open();

return cmd.ExecuteReader();

}

So it's really just another case of the danger of returning a deferred-execution object from within a using statement, which can be done with many things, such as a DataReader, an enumerator, a stream, or a lambda.

Different bugs can be caused by passing out such objects from inside a lock {} block, too.

re: Don't mix using statements and lambda expressions

Tanveer Badar — Thu, 14 Aug 2008 21:26:16 GMT

I think it is the C# version of this C++ code

int* dummy( )

{

int d = 0;

return &d;

}

Weekly Web Nuggets #21

Code Monkey Labs — Mon, 23 Feb 2009 06:47:53 GMT