Et si un finally est appelé par un return,
Et qu'il fait lui aussi un return ...
C'est illogique![]()
Et si un finally est appelé par un return,
Et qu'il fait lui aussi un return ...
C'est illogique![]()
@giova_fr
Aucun effet de bord, non.il y a t'il un piège si on place un return dans le try ou le catch? un effet de bord indésirable qui se produirait dans un cas particulier?
C'est pour cette raison que je tente de comprendre précisément comment se comporte finally, dans quel ordre se passent les choses...
En fait, la magie se passe au niveau de la génération du code IL. Si tu observes ce dernier, tu constates que le "return" que tu places dans ton bloc "try" ou "catch" est remplacé par une assignation à une variable locale. Le return est ensuite inséré après le bloc finally et renvoie le contenu de la variable locale en question.
Code c# : Sélectionner tout - Visualiser dans une fenêtre à part
1
2
3
4
5
6
7
8
9 // Code d'origine : try { return GimmeAnInteger(); } finally { CleanUp(); } // Le compilateur ce qui précède par ce qui suit : int __result; try { __result = GimmeAnInteger(); } finally { CleanUp(); } return __result;
@brachior et nah666
Quand j'ai parlé de placer le return après le finally, je ne voulais absolument pas dire que c'était mieux que de le placer dans le bloc try, c'était simplement dans le contexte de la question de savoir pourquoi on ne pouvait pas mettre de return dans le finally.
Alors est-ce mieux de mettre le return dans le try ou après le finally ? Bof, c'est une pure question stylistique, les deux se défendent.
Partager