Détectez les exceptions au sein d'un bloc utilisateur par rapport à l'extérieur du bloc utilisateur - quel est le meilleur?

Question

Y a-t-il une différence entre ces morceaux de code et quelle approche est la meilleure?

 try
{
    using()
    { 
      //Do stuff
    }
}
catch
{
    //Handle exception
}


using()
{
    try
    {
         //Do stuff
    }
    catch
    {
        //Handle exception
    }
}
 

Answer 1

Il existe des différences, mais cela se résume notamment au fait qu'un bloc using crée ses propres blocs try et scope.

 try
{
    using(IDisposable A = GetDisposable())
    { 
      //Do stuff
    }
}
catch
{
    //Handle exception
    // You do NOT have access to A
}


using(IDisposable A = GetDisposable())  //exception here is uncaught
{
    try
    {
         //Do stuff
    }
    catch
    {
        //Handle exception
        // You DO have access to A
    }
}
 

Answer 2

Il y a une différence entre ces blocs. Dans le second cas, l'exception ne sera pas interceptée si elle est levée dans la ligne using () (par exemple, l'instanciation d'un objet IDisposable et le constructeur lève une exception). Laquelle est la meilleure dépendra de vos besoins spécifiques.

Answer 3

Oui. Dans le premier, la ressource que vous "utilisez" sera supprimée avant l'exécution du bloc catch. Dans le dernier, il sera éliminé par la suite. De plus, l'instruction "foo" n'est pas couverte par la clause catch. Un bloc "utilisant" est du sucre presque syntaxique tel que

 using (foo)
{
}
 

est

 try
{
  foo;
}
finally
{
  foo.Dispose();
}
 

Quel comportement est "meilleur" n'est pas évident sans contexte.

Answer 4

En fin de compte, vous pouvez combiner les deux méthodes pour surmonter les deux inconvénients :

 IFoo f;
try{
  f = new Foo();
  f.Bar();
catch{
  // Do something exceptional with f
} finally{
  if(f != null) f.Dispose();
}
 

Answer 5

Je présume que tu veux dire:

using (var x = new Y(params))
{
}

Dans les deux cas? Ensuite, la différence la plus évidente est la portée de x. Dans le second cas, vous pouvez avoir accès à x dans la clause catch. Dans le premier cas, vous ne pourriez pas.

Je vais aussi profiter de l'occasion pour vous rappeler de ne pas "traiter" une exception à moins que vous pouvez vraiment faire quelque chose à ce sujet. Qui comprend l'enregistrement de l'exception, ce qui serait ok, sauf si l'environnement vous êtes d'exploitation de la journalisation pour vous (comme ASP.NET 2.0 par défaut).