Discussion :

[olibara]

Bonjour

Je n'ai pas encore trouvé la nécessité du finaly dans un try catch ?

Quelqu'un aurait-il un exemple dans lequel cette instruction est réellement nécessaire ?

Merci aux connaisseurs

[sevyc64]

Quelque soit ce qui se passe dans le Try (erreur ou pas erreur) le code dans le Finally est toujours executé

Schématiquement, par exemple, :

Try
- Ouverture d'une connexion avec verrou sur une base de données
- Diverses instructions
Catch
- Exception levée --> Affichage d'un message d'erreur
Finally
- Fermeture de la connexion à la base
End try

Si ton code dans le Try ne génère pas d'erreur, c'est OK.
S'il génère une erreur, l'exécution est déroutée vers le code dans Catch

Dans les 2 cas, systématiquement l'execution passera par le code du Finally et donc fermera la base et libèrera le verrou

Sans le finally, tu serais obligé de gérer la fermeture de la base, à la fois dans le Try et dans le Catch

[LeonardL]

Pour fermer une connexion à une base de donnée par exemple.

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
 
try
{
     connection.Open();
}
catch(Exception exp)
{
}
finally
{
     if(connection.State == ConnectionState.Open)
          connection.Close();
}

[olibara]

Salut

Pas vraiment convaincu !

Soit c'est l'ouverture de la base qui genere l'exeption et dans ce cas pas besoin de la fermer

Soit l'exception nécessite la fermeture de la base et on peut le faire dans le catch

Pour le moment je ne vois le finaly que comme un filet pour recuperer une logique égarée

Mais c'est que je n'ai peut etre pas encore bien compris la subtilité de la chose

[sevyc64]

Ok, mais quand tout se passe bien et qu'il n'y a pas d'exception dans ton code, tu la ferme quand ta connexion ????

[olibara]

Ben

Si la connexion est ouverte dans le try, je peux la fermer apres !!

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
try
{
  open ...;
}
catch
{
  // loupé
  return;
}
 
traitement;
close;

Personnelement je pense qu'un try ne doit servir qu'a proteger des petites parties de codes sensibles

J'ai le souvenir d'un génie en VB qui demarait son code avec un ON ERROR GOTO xxx

Mais il ne se contentait pas de ca : par ci par la il y avais d'autres ON ERROR GOTO xx1, xx2 etc
et dans xxx,xx1,xx2 il fermait l'application !
Un bel exemple de theorie pratique : Bravo le code ne plantait jamais (donc pas de bug ) Mais Rien ne se passe et personne ne sait pourquoi !

Un try catch mal encadré peut presque faire la meme chose

[jnspunk]

La seule utilité que je vois, c'est d'avoir un code plus organisé.

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
 
try
{
// connection à la base.
}
catch
{
// erreur.
}
finally
{
// fermeture de la base et affichage du résultat.
}

[Graffito]

Le "finally" me parait également sans grand intéret, même si on utilise des "catch" multiples qui chacun traite un type d'exception différent.

Sauf return ou throw exception dans { B } :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
try { A }
catch (Exception e) { B }
Finally { C }

est équivalent à

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
try { A }
catch (Exception e) { B }
C

[Pol63]

(jargon vb dans ce qui suit)

l'utilité du finally c'est que ca force l'execution du bloc, soit en sortie du try, soit en sortie du catch
on pourrait en théorie toujours s'en passer, mais ca permet un code plus lisible

si dans une fonction tu fais un return dans le try, le finally sera exécuté, alors que si ton code est hors du try finally, il ne le sera pas
pour s'en passer il faudrait alors setter une variable et faire exit try puis retourner cette variable donc plus de lignes de code et moins clair

autre cas, tu ouvres une connexion, tu fais return true dans le try, return false dans le catch et close sur le finally
pour se passer du finally il faudrait alors fermer la connexion dans le try si elle a fonctionné, mais aussi dans le catch si elle a fonctionné et qu'autre chose a planter
or c'est vraiment déconseillé d'avoir 2x le meme code, c'est dangeureux pour la maintenance du code


sinon les try catch il n'est pas interdit d'en mettre dans tous les membres, un message d'erreur du framework à la vue du client ca fait pas très pro
(si c'est juste pour camoufler c'est pas utile, le mieux est d'enregistrer pour pouvoir corriger les bugs)

[olibara]

Mmmouais !

Je n'ecris pas asser de VB pour juger en VB

Mais pour ma part il me semble qu'en C# on peut avoir un code bien lisible en se passant du finaly et il me semble meme que l'usage du finaly peut compliquer la lecture logique.

En conclusion il n'y a vraissemblablement rien d'indispensable dans le finaly
Si quelqu'un peut montrer un bout de code ou le Finaly s'avere precieux voir indispensable je reste ouvert au débat

[Pol63]

ca me semble clair, un return dans le try fait que le code après le try/catch n'est pas exécuté

il reste aussi le try finally sans catch, il peut arriver qu'on veuille laisser l'exception à l'appelant, dans ce cas le finally permet de fermer la connexion

de toute façon si c'est pour disposer des ressources le using reste plus approprié

[olibara]

il reste aussi le try finally sans catch, il peut arriver qu'on veuille laisser l'exception à l'appelant, dans ce cas le finally permet de fermer la connexion

C'est pour ca que je dis qu'il y a probablement des nuances d'ecriture entre VB et C# et que le finaly est sans doute plus pertinent en VB qu'en C#

Car en C# un Try / finaly sans catch equivaut a

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
try
{
   // qq chose
}
 
// autre chose que tu 'a pas besoin de mettre dans un finaly

[Guulh]

si dans une fonction tu fais un return dans le try, le finally sera exécuté, alors que si ton code est hors du try finally, il ne le sera pas

Ca me parait une raison déjà bien suffisante. Il est aussi vrai qu'en C# le mot-clé using (je sais pas s'il existe en VB.net ?) le remplace très souvent, vu que le genre de code que l'on veut exécuter à tout prix avant de quitter une méthode, c'est du code de nettoyage.

olibara : tes deux codes ne sont équivalents que s'il n'y a pas de "return" dans le bloc "try".

[Pol63]

(oui using existe en vb.net, mais absence d'accolades oblige, on a using et end using plus loin)

m'enfin tout dépend de la manière de coder de chacun
si tu découpes le plus de choses en fonction, tu fais forcément des return, donc des finally sont alors nécessaires ...

[bacelar]

Je ne voudrais pas faire le coupeur de cheveux en quatre mais les connections aux bases de données sont sujettes aux pooling de connexions et donc, il ne faudrait pas les fermer. (À moins que ce pooling n'existe quand ASP.NET ?)

Dire que sans un try/catch, il n'y aura que des problèmes à la connexion est très réducteur. N'avez-vous jamais eu à gérer des timeout dû à une base ou un réseau surchargé ?

Using réduit l'utilisation du finally, mais il faut bien comprendre que cela n'est que du "syntaxe sugar" car c'est un finally qui est utilisé en sous-main (cf. Reflector)

Un Log fonctionnel en sortie de méthode est un exemple comme un autre de l'utilisation de finally.

[Pol63]

il me semble que microsoft recommande de fermer les connexions sql server le plus tot possible et à chaque fois ...

et justement le pooling de connexions fait que des connexions sont déjà ouverte par sql server et en attente
et quand on en ouvre une, ca ne perd pas 5 secondes à créer la connexion, ca en distribue une

[bacelar]

Effectivement, je devrais dormir plus la nuit moi.

[neilbgr]

Dans le cas de l'écriture dans un flux, si on utilise pas le using, il est préférable d'utiliser un try finally :

Code c# :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
//Obtention du flux
try {
  //on joue avec le flux
} catch {
  //traitement des erreurs (ex: changement du type de l'erreur ainsi que son message)
  //Si pas de traitement, autant utiliser "using" qui s'occupera de faire le dispose qui fera le close
}
 finally {
  // On ferme impérativement le flux, car sinon il n'y aura pas de flush
  // Voire on appel Dispose()
}