Discussion :

[tchize_]

Bonjour,


aujourd'hui, je vous propose un sujet de débat. D'après vous,

est-ce un anti-pattern d'utiliser une instruction return dans un bloc try / catch / finally ? Faut-il par exemple éviter le return dans la catch? Faut-il éviter le return dans le try? Faut-il éviter le return dans le finally? Dans tous?Si vous avez, au contraire, des arguments à apporter par rapport à votre opinion, et que ceux-ci n'ont pas encore été apporté sur ce fil de discussion, n'hésitez pas fournir votre contribution.


Instructions:

• Si vous avez juste une impression ou une opinion à faire valoir, merci d'utiliser le sondage associé.
• si aucun point du sondage ne vous satisfait, décrivez sur ce fil de discussion votre point de vue, avec de préférence une argumentation
• inutile de mettre un message avec juste "je suis d'accord / je ne suis pas d'accord avec untel", les messages de ce type n'apportent rien au débat. Si vous désirez juste marquer votre accord avec un intervenant, utilisez le système de votes sur les messages (pouce levé / pouce descendu). Tout avis non argumenté sera susceptibles d'être supprimé pour faciliter la lecture
• Amenez des éléments concrets, des cas vécus, de l'expérience, des références dans le débat. Précisez bien le cadre de votre argumentation, car souvent des arguments ne s'appliquent que dans une cadre plus ou moins large, mais cependant précis.
• Les règles de developpez et de la section java s'appliquent sur ce sujet, tout particulièrement les règles de politesse. Tout un chacun a le droit de s'exprimer pour défendre son point de vue dans le respect mutuel. Tout message attaquant un intervenant et non son argumentation sera édité ou supprimé, ce genre de message n'apportant rien dans un débat.

[tchize_]

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.

[adiGuba]

Salut,

Pour le try et le catch, je ne vois pas de soucis particulier. Après bien sûr ca dépend des conventions de codage de chacun...

Par contre c'est une grosse erreur de mettre un return dans un bloc finally, car cela peut cacher un return ou même une exception remontée dans le bloc try correspondant. D'ailleurs le compilateur génère un warning dans ce cas...


a++

[edit] Grillé... mais tu as oublié de dire qu'un return dans le finally peut également cacher un éventuel return dans le bloc try. Par exemple cette méthode retournera toujours 0 :

Code :

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

1
2
3
4
5
6
7
8
	public static int method(boolean condition) {
		try {
			if (condition)
				return 1;
		} finally {
			return 0;
		}
	}

[thebloodyman]

De part le caractère trompeur du bloc finally pour les return, je l'exclus comme vous des possibilités intéressantes d' y mettre ou non un return à l'intérieur.
De ce postulat, je vois 2 logiques principales:
- celle ou on autorise un seul return : donc uniquement après la fin du catch.
- celle ou on autorise le catch à tout niveau (hormis finally) donc à la fois dans le try et le catch.

La 1ère solution présente généralement la présence d'une variable de sortie commune.

Code :

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

1
2
3
4
5
6
7
8
9
10
11
 
Objet objetToReturn=null;
//autres instructions ici
try{
objetToReturn = mafonction();
}
catch(Exception e){
//traitement exception
}
//autres instructions possibles ici
return objetToReturn;

La seconde solution avec 2 returns:

Code :

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

1
2
3
4
5
6
7
 
try{
return mafonction();
}
catch(Exception e){
return null;
}

A mon sens, la seconde question derrière celle du return dans le try/catch est celle que l'on peut se poser dans n'importe quel bloc d'instruction java (if,while,do...) :
Faut il ou non sortir d'une méthode voir d'une structure logique avec sa propre mécanique lorsqu'une condition de sortie est satisfaite ?

Personnellement, je répond oui car j'en trouve la qualité du code améliorée:
- on supprime toute les erreurs possibles que l'on peut faire lorsque l'on partage une variable de sortie commune entre les sorties potentielles et qu'on doit attendre la dernière instruction de la méthode pour sortir.
- le code est plus concis dans la mesure ou l'on peut inliner les valeurs retournées.
- le code se lit plus rapidement puisque plus d'indirection de lecture liée à l'existence d'une variable de sortie commune

[TIFéç]

Salut,

Dans ma boite un grand "ponte", nous à pondu des préconisations parmi lesquelles : "1 return au maximum par méthode". Partant de là, je dirai donc qu'il est préférable de ne jamais en mettre dans les try, catch, ou finally.

En même temps, je n'ai jamais vraiment compris en quoi mettre plusieurs return dans une même méthode pouvait gêner? Et c'est aussi le même qui nous à pondu une autre règle : "pas plus de 80 caractères par ligne", et là on devine qu'il édite les règles d'après son expérience sur ... cobol, et du coup je ne sais pas dire si il y a réellement une logique derrière cette limitation?

Si possible je m'abstiens de mettre des return dans "try" et "finally", et encore plus dans les "catch" où à priori je vois mieux un "throws" qu'un return?

[tchize_]

Salut,

Dans ma boite un grand "ponte", nous à pondu des préconisations parmi lesquelles : "1 return au maximum par méthode". Partant de là, je dirai donc qu'il est préférable de ne jamais en mettre dans les try, catch, ou finally.

Miam, tout ce qu'il faut pour ne pas trouver, dans le code, où la valeur de retour est déterminée

[deltree]

Je fais confiance aux warnings d'eclipse, et c'est toutes les sorties à partir du finalize qui sont en alerte sous eclipse. ça vaut aussi pour un throw exception dans le finalize.
Donc c'est clairement un antipattern, limite un WTF

par contre, je ne sais pas pourquoi tu as posé la question les return dans un try et un catch, ça c'est du traitement normal.

[_xme_]

Miam, tout ce qu'il faut pour ne pas trouver, dans le code, où la valeur de retour est déterminée

Pas taper moi, mais moi avis de grand ponte

Je préfère également n'avoir qu'un seul return, je trouve ça plus lisible et plus proche de ma réflexion:
"je tente ça et si ça échoue je détermine l'erreur, puis je retourne un résultat".
ou
"je fais calcule ça ou ca et je retourne le résultat"
Un return dans le code c'est pour moi plus une astuce d'optimisation qui sacrifie un peu de facilité de lecture.

Mon soucis vis-à-vis de cette discussion c'est que je ne vois pas vraiment de cas ou on ait besoin de setter quelque chose dans un catch.
Si je catch une exception, c'est que l'application a eu un comportement anormal et du coup, ce que je set dans le bloc catch sera plus une constante qui décrit le problème (donc pas de soucis pour déterminer qui set quoi), mais je vais surtout up mes log.
Je préfère d'ailleurs retourner un null lors d'une levé d'exception, comme ça pas de doute

[tchize_]

bien sur dans le final (et pas finalize!!!) SURTOUT pas de throw ou de return dedans!! Ca cacherais l'exception en cours de propagation.

[deltree]

Oops, ah oui, c'est du finally dont je parlais, pas du finalize.
bref l'anti-pattern pourrais faire l'objet d'une belle question piège pour les entretiens de recrutement, quoiqu'il soit sans doute plus utile de connaitre les bonnes méthodes que les mauvaises, notamment que faire dans le catch, quelle Exception catcher.

[Rei Ichido]

On m'a aussi dit au début "surtout, un seul return par méthode, sinon c'est illisible".

Très rapidement je suis passé outre - parce que je trouvais ça tellement plus lisible avec plusieurs returns qu'avec un stockage dans une variable qu'on teste à chaque bloc pour voir si elle est pas vide. Par ailleurs les classes java.lang sont pleines d'exemples de multi-return, ça m'a donné un argument contre les "pontes"