curioso C# expansión mediante declaración

Question

me he encontrado ildasm para encontrar que esto:

using(Simple simp = new Simple()) 
    { 
     Console.WriteLine("here"); 
    } 

genera código IL que es equivalente a esto:

Simple simp = new Simple(); 
    try 
    { 
     Console.WriteLine("here"); 
    } 
    finally 
    { 
     if(simp != null) 
     { 
      simp.Dispose(); 
     } 
    } 

y la pregunta es ¿por qué diablos lo hace comprobar nulo en el finalmente? El bloque finally solo se ejecutará si se ejecuta el bloque try, y el bloque try solo se ejecutará si el constructor Simple tiene éxito (es decir, no lanza una excepción), en cuyo caso simp será no nulo. (Si hay algún temor de que algunos pasos intermedios puedan venir entre el constructor Simple y el comienzo del bloque try, entonces eso sería realmente un problema porque entonces podría lanzarse una excepción que evitaría que el bloque finally se ejecute). Entonces, ¿por qué demonios?

Dejando a un lado (por favor) el argumento de si la instrucción using es mejor que tratar, por último, escribo mis try-finally bloques como:

Simple simp = new Simple(); 
    try 
    { 
     Console.WriteLine("here"); 
    } 
    finally 
    { 
     simp.Dispose(); 
     simp = null;  // sanity-check in case I touch simp again 
          // because I don't rely on all classes 
          // necessarily throwing 
          // ObjectDisposedException 
    } 

Answer 1

No, siempre se ejecutará el bloque finally. Es posible que no obtenga el objeto de una función nueva, sino de otra función que devuelve su objeto, y puede devolver NULO. using() es tu amigo!

dss539 fue tan amable de sugerir incluyo su nota:

using(Simple simp = null) 

es otra razón por la que la expansión debe comprobar primero nula.

Answer 2

using(Simple simp = null) es otra razón más que que primero debe comprobar la expansión para null.

Answer 3

MSDN en la instrucción using.

Lo que me parece extraño es que no se expande a:

Simple simp = new Simple(); 
Simple __compilergeneratedtmpname = simp; 
try 
{ 
    Console.WriteLine("here"); 
} 
finally 
{ 
    if(__compilergeneratedtmpname != null) 
    { 
     __compilergeneratedtmpname.Dispose(); 
    } 
} 

Answer 4

Parece que tu comentario:

"Si hay algún temor de que algunos pasos intermedios podrían venir entre la simple constructor y el comienzo del bloque try, entonces eso realmente sería un problema porque entonces podría lanzarse una excepción que evitaría que el bloque finally se ejecute en absoluto ".

es posible que esté muerto. Ver:

Atomicity & Asynchronous Exception Failures

También quiero destacar el tema (s) con WCF y usando:

Avoiding Problems with the Using Statement and WCF Service Proxies cuales referencias:

Avoiding Problems with the Using Statement