Affichage des résultats du sondage: Faut-il éviter les return dans un bloc try catch (choix multiples)

Votants
23. Vous ne pouvez pas participer à ce sondage.
  • Ne jamais mettre (autant que possible) de return dans un bloc try

    7 30,43%
  • Ne jamais mettre (autant que possible) de return dans un bloc catch

    7 30,43%
  • Ne jamais mettre (autant que possible) de return dans un bloc finally

    18 78,26%
  • Il n'y a aucun problème à utiliser un return dans un bloc try

    13 56,52%
  • Il n'y a aucun problème à utiliser un return dans un bloc catch

    12 52,17%
  • Il n'y a aucun problème à utiliser un return dans un bloc finally

    2 8,70%
Sondage à choix multiple
+ Répondre à la discussion
Affichage des résultats 1 à 11 sur 11
  1. #1
    Expert Confirmé Sénior
    Avatar de tchize_
    Homme Profil pro David Delbecq
    Responsable de service informatique
    Inscrit en
    avril 2007
    Messages
    21 826
    Détails du profil
    Informations personnelles :
    Nom : Homme David Delbecq
    Âge : 35
    Localisation : Belgique

    Informations professionnelles :
    Activité : Responsable de service informatique
    Secteur : Service public

    Informations forums :
    Inscription : avril 2007
    Messages : 21 826
    Points : 41 353
    Points
    41 353

    Par défaut Utiliser un return dans un bloc try / catch, un anti pattern ?

    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 (Чиз) faq java, cours java, javadoc. Pensez à et

  2. #2
    Expert Confirmé Sénior
    Avatar de tchize_
    Homme Profil pro David Delbecq
    Responsable de service informatique
    Inscrit en
    avril 2007
    Messages
    21 826
    Détails du profil
    Informations personnelles :
    Nom : Homme David Delbecq
    Âge : 35
    Localisation : Belgique

    Informations professionnelles :
    Activité : Responsable de service informatique
    Secteur : Service public

    Informations forums :
    Inscription : avril 2007
    Messages : 21 826
    Points : 41 353
    Points
    41 353

    Par défaut

    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.
    Tchize (Чиз) faq java, cours java, javadoc. Pensez à et

  3. #3
    Expert Confirmé Sénior
    Avatar de adiGuba
    Homme Profil pro
    Développeur Java/Web
    Inscrit en
    avril 2002
    Messages
    13 337
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France

    Informations professionnelles :
    Activité : Développeur Java/Web
    Secteur : Transports

    Informations forums :
    Inscription : avril 2002
    Messages : 13 337
    Points : 21 585
    Points
    21 585

    Par défaut

    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 :
    1
    2
    3
    4
    5
    6
    7
    8
    	public static int method(boolean condition) {
    		try {
    			if (condition)
    				return 1;
    		} finally {
    			return 0;
    		}
    	}

  4. #4
    Membre expérimenté
    Profil pro David
    Inscrit en
    décembre 2003
    Messages
    476
    Détails du profil
    Informations personnelles :
    Nom : David

    Informations forums :
    Inscription : décembre 2003
    Messages : 476
    Points : 570
    Points
    570

    Par défaut

    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 :
    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 :
    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
    Ils flottent tous en bas

  5. #5
    Membre éprouvé

    Homme Profil pro
    Chomeur
    Inscrit en
    juin 2006
    Messages
    298
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 32
    Localisation : France

    Informations professionnelles :
    Activité : Chomeur

    Informations forums :
    Inscription : juin 2006
    Messages : 298
    Points : 402
    Points
    402

    Par défaut

    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?
    Divers NTIC (PHP, Dojo, à venir...) : http://tif44.fr/blog/

  6. #6
    Expert Confirmé Sénior
    Avatar de tchize_
    Homme Profil pro David Delbecq
    Responsable de service informatique
    Inscrit en
    avril 2007
    Messages
    21 826
    Détails du profil
    Informations personnelles :
    Nom : Homme David Delbecq
    Âge : 35
    Localisation : Belgique

    Informations professionnelles :
    Activité : Responsable de service informatique
    Secteur : Service public

    Informations forums :
    Inscription : avril 2007
    Messages : 21 826
    Points : 41 353
    Points
    41 353

    Par défaut

    Citation Envoyé par TIFéç Voir le message
    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
    Tchize (Чиз) faq java, cours java, javadoc. Pensez à et

  7. #7
    Membre éclairé
    Inscrit en
    mai 2007
    Messages
    241
    Détails du profil
    Informations forums :
    Inscription : mai 2007
    Messages : 241
    Points : 300
    Points
    300

    Par défaut Warning dans eclipse

    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.

  8. #8
    Membre régulier
    Inscrit en
    juillet 2009
    Messages
    93
    Détails du profil
    Informations forums :
    Inscription : juillet 2009
    Messages : 93
    Points : 71
    Points
    71

    Par défaut

    Citation Envoyé par tchize_ Voir le message
    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

  9. #9
    Expert Confirmé Sénior
    Avatar de tchize_
    Homme Profil pro David Delbecq
    Responsable de service informatique
    Inscrit en
    avril 2007
    Messages
    21 826
    Détails du profil
    Informations personnelles :
    Nom : Homme David Delbecq
    Âge : 35
    Localisation : Belgique

    Informations professionnelles :
    Activité : Responsable de service informatique
    Secteur : Service public

    Informations forums :
    Inscription : avril 2007
    Messages : 21 826
    Points : 41 353
    Points
    41 353

    Par défaut

    bien sur dans le final (et pas finalize!!!) SURTOUT pas de throw ou de return dedans!! Ca cacherais l'exception en cours de propagation.
    Tchize (Чиз) faq java, cours java, javadoc. Pensez à et

  10. #10
    Membre éclairé
    Inscrit en
    mai 2007
    Messages
    241
    Détails du profil
    Informations forums :
    Inscription : mai 2007
    Messages : 241
    Points : 300
    Points
    300

    Par défaut

    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.

  11. #11
    Membre Expert
    Inscrit en
    août 2009
    Messages
    1 046
    Détails du profil
    Informations forums :
    Inscription : août 2009
    Messages : 1 046
    Points : 1 750
    Points
    1 750

    Par défaut

    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"

Liens sociaux

Règles de messages

  • Vous ne pouvez pas créer de nouvelles discussions
  • Vous ne pouvez pas envoyer des réponses
  • Vous ne pouvez pas envoyer des pièces jointes
  • Vous ne pouvez pas modifier vos messages
  •