Question

Donnez-moi une partie de vos réflexions sur ce qui est une meilleure pratique de codage / rend le code plus efficace / semble plus joli / peu importe: Augmenter et améliorer votre capacité à utiliser les déclarations if pour anticiper et déceler les problèmes potentiels? Ou simplement faire bon usage de try / catch en général?

Disons que c'est pour Java (si c'est important).

Modifier: Je suis actuellement en train de me démarquer de certaines pratiques de codage actuelles, certes obsolètes et contraignantes, mais je suis un peu déchiré sur la nécessité de le faire sur quelques points (tels comme cela). Je demande simplement quelques perspectives à ce sujet. Pas un débat.

Autres conseils

si les blocs sont légèrement plus rapides; si vous n’en avez pas besoin, c’est une meilleure idée que try / catch . Les exceptions doivent être exceptionnelles, pas à chaque fois que le code est exécuté. J'utilise des exceptions pour des événements rares tels que les déconnexions de serveur (même si elles se produisent plusieurs fois par jour), et des blocs si pour l'une de mes variables contrôlables.

Quel que soit le code que vous écrivez, vous finirez par utiliser les deux. Je ne peux pas parler pour le runtime Java, mais sur le runtime .NET, les performances sont associées à l'utilisation de blocs try-catch. En conséquence, j’essaie de les utiliser uniquement dans les zones où j’ai un moyen clair de gérer l’exception une fois interceptée (même si cela ne fait que consigner l’existence d’un problème).

Si vous utilisez beaucoup de blocs try-catch ou if-else dans votre code, ou si vos méthodes ont tendance à être assez longues, envisagez de refactoriser le code en un plus grand nombre de méthodes plus petites. L’intention de votre logique sera plus facile à suivre, mais aussi plus facile à tester un peu.

Je pense que si les déclarations sont meilleures. Vous ne pouvez pas entourer chaque ligne de code d'un try..catch (vous pouvez le faire, mais vous ne devriez pas le faire). Vous pouvez entourer un bloc de code avec try catch mais pas toutes les lignes.

Et les exceptions ralentissent les choses.

Mon 2p: Utiliser try / catch c'est mieux:

  • cela indique clairement aux autres codeurs que vous effectuez la gestion des exceptions
  • le compilateur comprend ce que vous faites et peut effectuer pour vous des contrôles de compilation plus appropriés

D'après mon expérience, l'utilisation de la logique if-conditionnelle rend plus difficile la distinction entre la gestion des erreurs et la logique métier.

D'après ce que me disent des développeurs et des analystes plus expérimentés, try / catch est davantage orienté objet et, si c'est plus procédural.

Personnellement, je m'en fiche.

Je suis conscient du fait qu'un essai / interception est plus lent et cause des problèmes de performances, mais si je vais utiliser une douzaine de ifs pour valider avant de pouvoir faire ce que je veux faire, j'utiliserai toujours un essai / attraper pour enregistrer sur le nombre de lignes de code.

Cela me simplifie tellement la vie de ne rien avoir à valider et si la déclaration échoue, faites ce que j’aurais fait dans mon bloc "Autre" ... dans mon bloc "Attrape".

Parfois, je joins évidemment certaines déclarations if à un essai / attrape, mais de toute façon.

J'utilise un if quand il n'y a qu'un petit nombre de choses à valider (1 ou 2) avant de faire ce que je dois faire.

Il y a une chose qui n'a pas été mentionnée ici.

Avec une instruction if-else, chaque fois que le code est exécuté, il est garanti qu'au moins 1 de la condition est évaluée et exécutée. Je suis sûr que nous savons tous comment un if-else-elseif fonctionne, mais soyons clairs ... la partie si de la déclaration sera toujours évaluée, si elle est fausse, alors la suivante else-if est évalué, et ainsi de suite jusqu'à ce qu'il ne reste que le else à évaluer.

L'utilisation d'une instruction if-else aura donc une incidence sur vos performances. Pas de manière significative (dans la plupart des cas), mais cela prend du temps CPU pour effectuer les évaluations.

Les instructions try-catch, et corrigez-moi si je me trompe, ne soyez pas pris en compte au moment de l'exécution tant qu'elles ne sont pas requises (c'est-à-dire qu'une exception est levée). Donc, le simple fait d’envelopper votre code dans un try-catch n’affectera pas les performances tant qu’une exception n’aura pas été capturée.

De plus, ce n’est pas la prise qui cause la performance, mais le lancer.

Un point important à souligner est que les instructions try-catch ne doivent JAMAIS être utilisées pour la logique conditionnelle. Ils ne doivent être utilisés que pour ce pour quoi ils sont conçus: la gestion des exceptions!

Il est essentiel de rattraper les exceptions, si vous savez quoi faire avec elles. Si vous n'avez aucun moyen de gérer correctement l'exception, vous devriez la laisser disparaître, car certains codes plus en amont pourraient avoir un meilleur moyen de les gérer.

C'est généralement une bonne idée de disposer d'un gestionnaire d'exceptions au plus haut niveau absolu de votre application pour intercepter les exceptions avant qu'elles ne soient vues par l'utilisateur. Cela est possible dans ASP.NET dans l'événement Application_Error du fichier global.asax. Dans d’autres langues / environnements, vous le feriez dans votre boucle principale, quelle qu’elle soit.

Notez cependant qu'il existe certaines exceptions qu'il vaut mieux ne jamais prendre. Parfois, lorsqu'une exception survient, cela indique que l'état de votre application a été gravement compromis et ne peut pas être approuvé. La seule chose à faire est de tuer et de redémarrer.

@PersonalPerson - Désolé, mais c'est juste du codage paresseux. Plutôt que d'utiliser try-catch car il y a trop d'instructions if, pourquoi ne pas refactoriser votre code (c'est-à-dire mettre votre logique de validation dans sa propre méthode). Cela maintiendra votre code plus propre et plus lisible et maintiendra les meilleures pratiques en termes de performances.

N'essayez jamais d'écrire votre code pour obtenir le moins de lignes possible. Cela finira toujours mal. Bien sûr, vous pouvez trouver un moyen plus élégant d’écrire quelque chose qui plaira à vos amis codeurs, mais cela rend les choses moins lisibles.

Je jure que j'ai déjà travaillé avec votre code et que ça m'a fait mal à la tête.

L’utilisation d’exceptions est une méthode universelle pour notifier à une autre partie du code qu’une anomalie est survenue de manière faiblement couplée. Imaginons que si vous souhaitez gérer certaines conditions exceptionnelles en utilisant if .. nad else .. vous devez insérer dans une partie différente de votre code des variables arbitraires et d'autres éléments susceptibles de conduire facilement à un code spaghetti peu de temps après.

Imaginons maintenant que vous utilisez une bibliothèque / un paquet externe et que son auteur a décidé de mettre dans son code une autre manière arbitraire de gérer les états erronés - cela vous obligerait à vous adapter à sa manière de le gérer - par exemple vous auriez besoin de vérifier si des méthodes particulières retournent vrai ou faux ou quoi que ce soit.

L'utilisation d'exceptions facilite beaucoup la gestion des erreurs - vous supposez que si quelque chose ne va pas - l'autre code lève une exception, vous devez donc le placer dans un bloc try et gérer les exceptions possibles à votre façon.

Licencié sous: CC-BY-SA avec attribution
Non affilié à StackOverflow
scroll top