Curieux C# en utilisant l'expansion de l'instruction

Question

J'ai couru ildasm de constater que ceci:

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

génère du code IL qui est équivalent à ceci:

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

et la question est pourquoi diable il fait vérifier null dans le finalement? Le bloc finally ne sera exécuté que si le bloc try est exécuté, et le bloc try ne sera exécuté que si le constructeur Simple réussit (c'est-à-dire qu'il ne lance pas d'exception), auquel cas simp sera non nul. (S'il y a une certaine crainte que certaines étapes interviennent entre le constructeur Simple et le début du bloc try, alors ce serait vraiment un problème car alors une exception pourrait être lancée qui empêcherait le bloc finally de s'exécuter du tout.) Alors, pourquoi diable?

Mettant de côté (s'il vous plaît) l'argument de savoir si la déclaration à l'aide est mieux que d'essayer-enfin, je vous écris mes try-finally blocs comme:

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

Non, le bloc finally sera toujours exécuté. Vous ne pouvez pas obtenir l'objet d'une nouvelle mais d'une autre fonction qui renvoie votre objet - et il pourrait renvoyer NULL. using() est votre ami!

dss539 a eu la gentillesse de proposer sa note j'inclure:

using(Simple simp = null) 

est encore une autre raison pour que l'expansion doit vérifier nulle première.

Answer 2

using(Simple simp = null) est encore un autre raison que l'expansion doit d'abord vérifier null.

Answer 3

MSDN dans l'instruction using.

Ce que je pense est étrange est qu'il ne se développe pas:

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

Answer 4

Il semble que votre commentaire:

«S'il y a une certaine crainte que certaines étapes intermédiaires pourraient venir entre le simple constructeur et le début du bloc try, alors ce serait vraiment un problème car alors une exception pourrait être lancée qui empêcherait le bloc finally de s'exécuter du tout. "

est peut-être mort. Voir:

Atomicity & Asynchronous Exception Failures

Je veux également souligner la question (s) avec WCF et en utilisant:

Avoiding Problems with the Using Statement and WCF Service Proxies dont les références:

Avoiding Problems with the Using Statement