Est-ce une mauvaise pratique de revenir depuis un bloc try catch enfin?

Je suis donc tombé sur un code ce matin qui ressemblait à ceci:

try
{
    x = SomeThingDangerous();
    return x;
}
catch (Exception ex)
{
    throw new DangerousException(ex);
}
finally
{
    CleanUpDangerousStuff();
}

Maintenant, ce code se compile correctement et fonctionne comme il se doit, mais il ne semble pas juste de revenir à partir d'un bloc try, surtout s'il y a finalement un associé.

Mon principal problème est que se passe-t-il si le lance finalement une exception de sa part? Vous avez une variable retournée mais aussi une exception à traiter ... donc je suis intéressé de savoir ce que les autres pensent du retour d'un bloc try?

Non, ce n'est pas une mauvaise pratique. Mettre returnlà où cela a du sens améliore la lisibilité et la maintenabilité et rend votre code plus simple à comprendre. Vous ne devriez pas vous en soucier car le finallybloc sera exécuté si une returninstruction est rencontrée.

Le Final sera exécuté quoi qu'il arrive, donc peu importe.

Personnellement, j'éviterais ce genre de codage car je n'ai pas envie de voir les déclarations return avant les déclarations finally.

Mon esprit est simple et il traite les choses de manière plutôt linéaire. Par conséquent, lorsque je parcourrai le code de la marche à sec, j'aurai tendance à penser qu'une fois que je pourrai atteindre l'instruction de retour, tout ce qui suit n'a pas d'importance, ce qui est évidemment assez faux dans ce cas (non pas que cela affecterait l'instruction de retour, mais quels pourraient être les effets secondaires).

Ainsi, j'arrangerais le code de sorte que l'instruction return apparaisse toujours après les instructions finally.

Cela peut répondre à votre question

Que se passe-t-il vraiment lors d'un essai {return x; } enfin {x = null; } déclaration?

En lisant cette question, il semble que vous puissiez avoir une autre structure try catch dans l'instruction finally si vous pensez qu'elle pourrait lever une exception. Le compilateur déterminera quand renvoyer la valeur.

Cela dit, il serait peut-être préférable de restructurer votre code de toute façon pour ne pas vous embrouiller plus tard ou quelqu'un d'autre qui pourrait ne pas être au courant de cela également.

Fonctionnellement, il n'y a pas de différence.

Cependant, il y a une raison pour ne pas le faire. Les méthodes plus longues avec plusieurs points de sortie sont souvent plus difficiles à lire et à analyser. Mais cette objection a plus à voir avec les instructions return qu'avec les blocs catch et finally.

Dans votre exemple, l'une ou l'autre manière est équivalente, je ne serais même pas surpris si le compilateur générait le même code. Si une exception se produit dans le bloc finally, vous rencontrez les mêmes problèmes que vous placiez l'instruction return dans le bloc ou en dehors de celui-ci.

La vraie question est stylistiquement ce qui est le mieux. J'aime écrire mes méthodes pour qu'il n'y ait qu'une seule instruction return, de cette façon, il est plus facile de voir le flux de la méthode, il s'ensuit que j'aime aussi mettre l'instruction return en dernier, donc il est facile de voir que c'est la fin de la méthode et ce qu'elle renvoie.

Je pense qu'avec la déclaration de retour si bien placée comme dernière déclaration, d'autres sont moins susceptibles de venir et de saupoudrer plusieurs déclarations de retour dans d'autres parties de la méthode.