Performances des try/catch en Java, est-il recommandé de réduire au minimum ce qui se trouve à l'intérieur de la clause try ?

Question

Considérant que vous avez un code comme celui-ci :

doSomething() // this method may throw a checked a exception
//do some assignements calculations
doAnotherThing() //this method may also throw the same type of checked exception
//more calls to methods and calculations, all throwing the same kind of exceptions.

Je sais maintenant qu'il y a en fait un impact sur les performances lors de la construction de l'exception, en particulier lors du déroulement de la pile. J'ai également lu plusieurs articles faisant état d'une légère baisse des performances lors de l'entrée dans les blocs try/catch, mais aucun de ces articles ne semble conclure quoi que ce soit.

Ma question est la suivante : est-il recommandé de limiter les lignes à l'intérieur de la clause try catch au strict minimum ? c'est-à-dire de n'avoir à l'intérieur de la clause try que les lignes qui peuvent effectivement lancer l'exception que vous attrapez. Le code à l'intérieur de la clause try s'exécute-t-il plus lentement ou entraîne-t-il une baisse des performances ?

Mais le plus important, c'est que c'est la meilleure pratique/la solution la plus lisible pour faire cela :

try {
    doSomething() // this method may throw a checked a exception
//do some assignements calculations
doAnotherThing() //this method may also throw the same type of checked exception
//more calls to methods and calculations, all throwing the same kind of exceptions.
}
catch (MyCheckedException e) {
   //handle it
}

ou :

try {
    doSomething() // this method may throw a checked a exception
}
catch (MyCheckedException e) {
   //Store my exception in a Map (this is all running in a loop and I want it to   continue running, but I also want to know which loops didn't complete and why)
   continue;     
} 
 //do some assignements calculations
try {
    doAnotherThing() // this method may throw a checked a exception
}
catch (MyCheckedException e) {
    //Store my exception in a Map (this is all running in a loop and I want it to   continue running, but I also want to know which loops didn't complete and why)
   continue;
} 

Ceci en considérant que vous traiterez TOUTES ces exceptions vérifiées exactement de la même manière bien sûr.

Answer 1

Est-il recommandé de garder les lignes à l'intérieur de la prise d'essai au strict minimum ?

Non.

Est-ce que le code à l'intérieur de la clause try s'exécute-t-il plus lentement ou provoque-t-il une performances ?

Non.

Comme vous l'avez observé, les exceptions n'entraînent des coûts de performance que lorsqu'elles sont lancées.

Si vous vous préoccupez des performances de "l'essai", la chose à faire est certainement de limiter le code à l'intérieur d'un fichier de type maximum ?

Answer 2

Dans votre exemple, le véritable impact sur les performances se produit si doSomething() et doAnotherThing() lèvent tous deux des exceptions. Entrer dans un bloc d'essai est rapide, jusqu'à ce qu'il lève une exception.

Cela dépend vraiment de votre situation. Si vous avez besoin de faire la même chose lorsque l'exception MyCheckedException est levée d'une manière ou d'une autre, je considérerais qu'il est à la fois plus lisible et plus performant de les avoir tous les deux dans le même bloc try, mais si vous avez besoin de gérer les deux situations différentes, alors bien sûr il est plus logique de les séparer.

Edit : J'ai lu la fin de votre commentaire, vous supposez que vous traitez les deux de la même manière, dans ce cas je les mettrais tous les deux dans le même bloc d'essai.

Answer 3

Je ne suis pas sûr de savoir lequel est le plus lent, mais n'oubliez pas qu'une try Le bloc est un flux de contrôle. Vous devez faire en sorte que le flux de contrôle corresponde à ce que vous essayez d'accomplir. Pour moi, le choix entre

try {
    // op 1.
    // op 2.
    / ...
    // op n.
}
catch ( MyCheckedException error )
{
    // handle any `MyException` in op 1, 2 ... n.
}

et séparer catch pour chacun d'eux est principalement une décision de savoir si je veux faire un traitement différent pour chaque opération, continuer à exécuter jusqu'à ce que l'opération soit terminée. n sans tenir compte des erreurs ou essayer de les exécuter toutes et échouer à la première erreur.

écrire un code propre et lisible, et puis la recherche de goulots d'étranglement. Si les expériences existantes ne permettent pas de conclure à des directives de base, je pense que ce n'est pas là que vous trouverez vos goulets d'étranglement de toute façon.

Answer 4

Le fait d'avoir des blocs d'essai ne devrait avoir pratiquement aucun effet sur les performances dans toute JVM décente. Le véritable problème survient lorsqu'une exception est effectivement levée.

Vous pouvez lire cet article pour avoir une idée de la manière dont la JVM met en œuvre la gestion des exceptions dans le bytecode : elle crée des "tables d'exceptions" qui font correspondre des régions de code à des blocs catch/finally, ainsi :

• Le bytecode d'un bloc d'essai est le même que celui d'un bloc standard { }.
• Le seul coût supplémentaire dans le cas d'un non-lancement est celui d'avoir la "table des exceptions" chargée en mémoire.

Bien sûr, lorsqu'une exception est levée, il y a beaucoup de travail sur la pile, ce qui a un coût. Quoi qu'il en soit, ce n'est pas aussi grave qu'avec SEH (exceptions .NET).

Answer 5

Votre code ne doit traiter que les exceptions pour lesquelles il peut faire quelque chose, les autres doivent être rejetées.

La quantité de code dans le bloc try ne provoque pas de ralentissement, c'est le bloc catch qui en provoque. Mais à moins que vous n'essayiez d'écrire un code vraiment performant, je ne m'en préoccuperais pas.