2010-11-18 16 views
1
using (SqlConnection sqlConn = new SqlConnection(XYZ.Globals.ConnectionString)) 
{                     
    using (SqlDataAdapter adapter = new SqlDataAdapter())        
    {                     
     SqlCommand command = new SqlCommand("selCompanies", sqlConn)  
     {                   
      CommandType = CommandType.StoredProcedure        
     };                  
     command.Parameters.AddRange(searchParams.ToArray());       
     adapter.SelectCommand = command;            
     DataSet ds = new DataSet();             
     adapter.Fill(ds);                

     return ds;                 
    }                     
}                      
                         Do I need to wrap the `adapter.fill()` in try catch finally block? 
+1

Attrapez seulement si vous pouvez gérer tout ce qu'il jette. –

+0

L'extrait de code ci-dessus ne contient pas les instructions permettant d'ouvrir et de fermer la connexion db. Tout en assainissant le code, je les ai supprimés. –

Répondre

0

Cela dépend si ce code est encapsulé pour la gestion des exceptions à un niveau supérieur. À quelle portée voulez-vous gérer les erreurs dans cette logique - typiquement ce serait pour un «bloc» donné de logique, pas pour chaque appel de fonction. La gestion des erreurs de DB est une bonne idée en général.

Dans tous les cas, vous devez avoir un autre using sur votre SqlCommand ou vous le fuire.

+0

Si je place le SqlCommand avec une instruction using, il n'y aura pas de fuite, lorsqu'une exception est levée. Est-ce correct? –

+0

@ Full Metal - oui, si c'est votre logique complète. –

+0

Eh bien, en fait, 'SqlCommand' ne fuit pas (regardez dans Reflector). Vous avez raison, bien sûr, que * en principe * tout ce qui est "IDisposable" devrait être "using". ('SqlCeCommand', par exemple, * fuit * s'il n'est pas disposé correctement ...) – Heinzi

1

Vous enveloppez uniquement les éléments dans un try/catch lorsque vous pouvez gérer les exceptions qu'il génère. Si vous ne pouvez pas, il n'est pas nécessaire de le mettre dans un bloc try/catch. L'instruction using est équivalente à un bloc try/finally.

0

de même cette adapter.Fill() à toute autre ligne de code .net:

Si vous avez une bonne raison pour la capture et la manipulation d'une exception particulière, puis l'attraper et manipuler. Si vous n'avez pas une bonne raison, ne l'attrapez pas.

Je ne vois pas pourquoi cette ligne particulière devrait être gérée d'une manière spécifique.

1

La question serait que ferais-je différemment si quelque chose se passait mal. En règle générale, l'action correcte consiste à laisser l'exception augmenter vers le haut - après tout, vous n'avez pas attendre une exception, donc vous ne pouvez rien faire d'utile avec. La seule subtilité ici est IDisposable, où vous voulez activement nettoyer les choses comme vous allez; donc using déclarations pour des choses comme SqlConnection, SqlCommand, SqlDataReader etc sont idéales (Mais c'est try/finally, pas try/catch). Donc, le principal changement que je ferais le code de la visite serait de disposer de la commande:

using (SqlDataAdapter adapter = new SqlDataAdapter()) 
using (SqlCommand command = new SqlCommand("selCompanies", sqlConn)) 
{ 
    command.CommandType = CommandType.StoredProcedure; 
    //...snip... 
} 
+0

Je veux m'assurer que si quelque chose ne va pas, je fermerais la connexion. Est-ce que mon extrait de code guarntee ça? –

+0

+1.Je suis confronté à cela dans mon application, les gens ne disposent pas des objets SQLCommand de façon déterministe. –

+0

Merci Marc, maintenant je comprends. L'instruction "using" génère try et finalement, si j'enveloppe un objet IDisposable en utilisant, alors il sera éliminé correctement. D'un autre côté, si vous souhaitez gérer explicitement l'utilisation de l'exception, essayez d'attraper finalement. –

0

Vous ne devez attraper l'exception du remplissage ici si vous avez la gestion des erreurs qui nécessite la connexion ou la commande d'être portée .

En outre, techniquement, l'adaptateur et la commande sortiront du cadre dès que vous quitterez le bloc d'utilisation pour la connexion. Dans de nombreux cas, cela est probablement suffisant pour libérer ces ressources (la connexion est la ressource la plus précieuse dans la plupart des scénarios, car elle crée une surcharge sur le serveur de base de données). Cela ne fait cependant pas de mal d'être explicite, surtout si vous créez plusieurs commandes ou adaptateurs pour la même connexion.