Dans un bloc try:
Pour moi, aucune raison d'éviter le return. Il est préférable de faire un return quand on sais qu'on a fini le travail et qu'on a le résultat (de calcul par exemple) à envoyer, que de stocker ça dans une variable, rajouter dans la suite du code des if pour traiter le cas "on a plus rien à faire mais on a encore plein de code" et finalement finir sa méthode avec un "return resultatDejaCalculeDepuisLongtemps;"
Dans le bloc catch:
Typiquement, certains cas d'erreur en eux même portent la réponse au calcul pour lequel la méthode est appelée ou sont tellement grave qu'il rendent la suite de l'opération impossible à continuer. Là, l'utilisation peut être tendancieuse. Il faut bien savoir ce que l'on fait. Faut-il ou non avertir l'appelant que la méthode a échoué? Quels moyens ont étés prévu dans le design pour informer l'appelant (return false? Ou lancement d'un autre exception). Suivant ces conditions, il faudra alors envisager soit le return, soit le lancement d'une autre exception.
Dans le bloc finally:
Ce bloc est "toujours" exécuté, par définition même (quoi que pas toujours intégralement). Deux cas peuvent alors se produire je pense:
- exécuté suite à la fin normale du try, donc sans exception ou avec une exception catchée et sans nouvelles exception: mettre un return dans le finally peut, en général etre décallé de quelque ligne vers la bas, après le finally, sans conséquence pour la complexité de lecture du code, sans nécessité de variables supplémentaires, donc sans dommages.
- exécuté suite au lancement d'une exception. Dans ce cas, l'appel à return dans le finally va cacher l'exception, personne ne saura jamais qu'elle s'est déclenchée, on aura jsute vraisemblablement un résultat bizzare.
Etant donné qu'on a pas de gain à mettre le return dans un finally "en général" et que le mettre dans le finally cause des problèmes de gestion d'exception, alors là oui, il faut éviter.
Partager