Devrait essayer… attraper à l'intérieur ou à l'extérieur d'une boucle?

J'ai une boucle qui ressemble à ceci:

for (int i = 0; i < max; i++) {
    String myString = ...;
    float myNum = Float.parseFloat(myString);
    myFloats[i] = myNum;
}

C'est le contenu principal d'une méthode dont le seul but est de renvoyer le tableau de flottants. Je veux que cette méthode retourne nulls'il y a une erreur, donc je mets la boucle dans un try...catchbloc, comme ceci:

try {
    for (int i = 0; i < max; i++) {
        String myString = ...;
        float myNum = Float.parseFloat(myString);
        myFloats[i] = myNum;
    }
} catch (NumberFormatException ex) {
    return null;
}

Mais j'ai aussi pensé à mettre le try...catchbloc à l'intérieur de la boucle, comme ceci:

for (int i = 0; i < max; i++) {
    String myString = ...;
    try {
        float myNum = Float.parseFloat(myString);
    } catch (NumberFormatException ex) {
        return null;
    }
    myFloats[i] = myNum;
}

Y a-t-il une raison, une performance ou autre, de préférer l'un à l'autre?

Edit: Le consensus semble être qu'il est plus propre de mettre la boucle à l'intérieur du try / catch, éventuellement dans sa propre méthode. Cependant, il y a encore un débat sur lequel est le plus rapide. Quelqu'un peut-il tester cela et revenir avec une réponse unifiée?

PERFORMANCE:

Il n'y a absolument aucune différence de performance dans l'emplacement des structures try / catch. En interne, ils sont implémentés en tant que table de plages de codes dans une structure créée lorsque la méthode est appelée. Pendant que la méthode s'exécute, les structures try / catch sont complètement hors de l'image à moins qu'un renvoi ne se produise, puis l'emplacement de l'erreur est comparé à la table.

Voici une référence: http://www.javaworld.com/javaworld/jw-01-1997/jw-01-hood.html

Le tableau est décrit à mi-chemin environ.

Performance : comme l'a dit Jeffrey dans sa réponse, en Java, cela ne fait pas beaucoup de différence.

En règle générale , pour la lisibilité du code, votre choix de l'endroit où intercepter l'exception dépend de si vous voulez que la boucle continue le traitement ou non.

Dans votre exemple, vous êtes revenu après avoir détecté une exception. Dans ce cas, je mettrais le try / catch autour de la boucle. Si vous voulez simplement attraper une mauvaise valeur mais continuer le traitement, mettez-la à l'intérieur.

La troisième façon : vous pouvez toujours écrire votre propre méthode statique ParseFloat et gérer la gestion des exceptions dans cette méthode plutôt que dans votre boucle. Rendre la gestion des exceptions isolée de la boucle elle-même!

class Parsing
{
    public static Float MyParseFloat(string inputValue)
    {
        try
        {
            return Float.parseFloat(inputValue);
        }
        catch ( NumberFormatException e )
        {
            return null;
        }
    }

    // ....  your code
    for(int i = 0; i < max; i++) 
    {
        String myString = ...;
        Float myNum = Parsing.MyParseFloat(myString);
        if ( myNum == null ) return;
        myFloats[i] = (float) myNum;
    }
}

D'accord, après que Jeffrey L Whitledge ait dit qu'il n'y avait pas de différence de performance (à partir de 1997), je suis allé le tester. J'ai couru ce petit benchmark:

public class Main {

    private static final int NUM_TESTS = 100;
    private static int ITERATIONS = 1000000;
    // time counters
    private static long inTime = 0L;
    private static long aroundTime = 0L;

    public static void main(String[] args) {
        for (int i = 0; i < NUM_TESTS; i++) {
            test();
            ITERATIONS += 1; // so the tests don't always return the same number
        }
        System.out.println("Inside loop: " + (inTime/1000000.0) + " ms.");
        System.out.println("Around loop: " + (aroundTime/1000000.0) + " ms.");
    }
    public static void test() {
        aroundTime += testAround();
        inTime += testIn();
    }
    public static long testIn() {
        long start = System.nanoTime();
        Integer i = tryInLoop();
        long ret = System.nanoTime() - start;
        System.out.println(i); // don't optimize it away
        return ret;
    }
    public static long testAround() {
        long start = System.nanoTime();
        Integer i = tryAroundLoop();
        long ret = System.nanoTime() - start;
        System.out.println(i); // don't optimize it away
        return ret;
    }
    public static Integer tryInLoop() {
        int count = 0;
        for (int i = 0; i < ITERATIONS; i++) {
            try {
                count = Integer.parseInt(Integer.toString(count)) + 1;
            } catch (NumberFormatException ex) {
                return null;
            }
        }
        return count;
    }
    public static Integer tryAroundLoop() {
        int count = 0;
        try {
            for (int i = 0; i < ITERATIONS; i++) {
                count = Integer.parseInt(Integer.toString(count)) + 1;
            }
            return count;
        } catch (NumberFormatException ex) {
            return null;
        }
    }
}

J'ai vérifié le bytecode résultant en utilisant javap pour m'assurer que rien n'était incorporé.

Les résultats ont montré que, en supposant des optimisations JIT insignifiantes, Jeffrey a raison ; il n'y a absolument aucune différence de performances sur Java 6, machine virtuelle client Sun (je n'avais pas accès à d'autres versions). La différence de temps totale est de l'ordre de quelques millisecondes sur l'ensemble du test.

Par conséquent, la seule considération est ce qui semble le plus propre. Je trouve que la deuxième manière est moche, donc je m'en tiendrai à la première ou à celle de Ray Hayes .

Bien que les performances puissent être les mêmes et que ce qui «semble» le mieux soit très subjectif, il y a encore une assez grande différence de fonctionnalité. Prenons l'exemple suivant:

Integer j = 0;
    try {
        while (true) {
            ++j;

            if (j == 20) { throw new Exception(); }
            if (j%4 == 0) { System.out.println(j); }
            if (j == 40) { break; }
        }
    } catch (Exception e) {
        System.out.println("in catch block");
    }

La boucle while est à l'intérieur du bloc try catch, la variable 'j' est incrémentée jusqu'à ce qu'elle atteigne 40, imprimée lorsque j mod 4 est à zéro et une exception est levée lorsque j atteint 20.

Avant tout détail, voici l'autre exemple:

Integer i = 0;
    while (true) {
        try {
            ++i;

            if (i == 20) { throw new Exception(); }
            if (i%4 == 0) { System.out.println(i); }
            if (i == 40) { break; }

        } catch (Exception e) { System.out.println("in catch block"); }
    }

Même logique que ci-dessus, la seule différence est que le bloc try / catch est maintenant à l'intérieur de la boucle while.

Voici la sortie (en try / catch):

4
8
12 
16
in catch block

Et l'autre sortie (try / catch in while):

4
8
12
16
in catch block
24
28
32
36
40

Là, vous avez une différence assez significative:

tandis que dans try / catch sort de la boucle

try / catch in while garde la boucle active

Je suis d'accord avec tous les articles sur les performances et la lisibilité. Cependant, il y a des cas où cela importe vraiment. Quelques autres personnes l'ont mentionné, mais cela pourrait être plus facile à voir avec des exemples.

Considérez cet exemple légèrement modifié:

public static void main(String[] args) {
    String[] myNumberStrings = new String[] {"1.2345", "asdf", "2.3456"};
    ArrayList asNumbers = parseAll(myNumberStrings);
}

public static ArrayList parseAll(String[] numberStrings){
    ArrayList myFloats = new ArrayList();

    for(int i = 0; i < numberStrings.length; i++){
        myFloats.add(new Float(numberStrings[i]));
    }
    return myFloats;
}

Si vous voulez que la méthode parseAll () renvoie null s'il y a des erreurs (comme l'exemple d'origine), vous placez le try / catch à l'extérieur comme ceci:

public static ArrayList parseAll1(String[] numberStrings){
    ArrayList myFloats = new ArrayList();
    try{
        for(int i = 0; i < numberStrings.length; i++){
            myFloats.add(new Float(numberStrings[i]));
        }
    } catch (NumberFormatException nfe){
        //fail on any error
        return null;
    }
    return myFloats;
}

En réalité, vous devriez probablement renvoyer une erreur ici au lieu de null, et généralement je n'aime pas avoir plusieurs retours, mais vous voyez l'idée.

D'un autre côté, si vous voulez qu'il ignore simplement les problèmes et analyse toutes les chaînes qu'il peut, vous placez le try / catch à l'intérieur de la boucle comme ceci:

public static ArrayList parseAll2(String[] numberStrings){
    ArrayList myFloats = new ArrayList();

    for(int i = 0; i < numberStrings.length; i++){
        try{
            myFloats.add(new Float(numberStrings[i]));
        } catch (NumberFormatException nfe){
            //don't add just this one
        }
    }

    return myFloats;
}

Comme déjà mentionné, les performances sont les mêmes. Cependant, l'expérience utilisateur n'est pas nécessairement identique. Dans le premier cas, vous échouerez rapidement (c'est-à-dire après la première erreur), cependant si vous placez le bloc try / catch dans la boucle, vous pouvez capturer toutes les erreurs qui seraient créées pour un appel donné à la méthode. Lors de l'analyse d'un tableau de valeurs à partir de chaînes où vous vous attendez à des erreurs de formatage, il y a certainement des cas où vous souhaitez pouvoir présenter toutes les erreurs à l'utilisateur afin qu'il n'ait pas besoin d'essayer de les corriger une par une .

Si c'est un échec du tout ou rien, alors le premier format a du sens. Si vous souhaitez pouvoir traiter / renvoyer tous les éléments non défaillants, vous devez utiliser le deuxième formulaire. Ce seraient mes critères de base pour choisir entre les méthodes. Personnellement, si c'est tout ou rien, je n'utiliserais pas la deuxième forme.

Tant que vous êtes conscient de ce que vous devez accomplir dans la boucle, vous pouvez mettre le crochet d'essai en dehors de la boucle. Mais il est important de comprendre que la boucle se terminera alors dès que l'exception se produira et que ce n'est peut-être pas toujours ce que vous souhaitez. Il s'agit en fait d'une erreur très courante dans les logiciels Java. Les utilisateurs doivent traiter un certain nombre d'éléments, tels que vider une file d'attente, et s'appuyer à tort sur une instruction try / catch externe gérant toutes les exceptions possibles. Ils peuvent également ne gérer qu'une exception spécifique à l'intérieur de la boucle et ne pas s'attendre à ce qu'une autre exception se produise. Ensuite, si une exception se produit qui n'est pas gérée à l'intérieur de la boucle, alors la boucle sera "pré-émise", elle se terminera peut-être prématurément et l'instruction catch externe gère l'exception.

Si la boucle avait pour rôle dans la vie de vider une file d'attente, alors cette boucle pourrait très probablement se terminer avant que cette file d'attente ne soit réellement vidée. Faute très courante.

Dans vos exemples, il n'y a pas de différence fonctionnelle. Je trouve votre premier exemple plus lisible.

Vous devriez préférer la version externe à la version interne. Ceci est juste une version spécifique de la règle, déplacez tout ce qui est en dehors de la boucle que vous pouvez déplacer en dehors de la boucle. En fonction du compilateur IL et du compilateur JIT, vos deux versions peuvent ou non se retrouver avec des caractéristiques de performances différentes.

Sur une autre note, vous devriez probablement regarder float.TryParse ou Convert.ToFloat.

Si vous mettez le try / catch dans la boucle, vous continuerez à boucler après une exception. Si vous le mettez en dehors de la boucle, vous vous arrêterez dès qu'une exception est levée.

Mon point de vue serait que les blocs try / catch sont nécessaires pour assurer une gestion correcte des exceptions, mais la création de tels blocs a des implications sur les performances. Puisque les boucles contiennent des calculs répétitifs intensifs, il n'est pas recommandé de mettre des blocs try / catch à l'intérieur des boucles. De plus, il semble que là où cette condition se produit, c'est souvent «Exception» ou «RuntimeException» qui est interceptée. RuntimeException interceptée dans le code doit être évitée. Encore une fois, si vous travaillez dans une grande entreprise, il est essentiel de consigner correctement cette exception ou d'arrêter que l'exception d'exécution se produise. Le point entier de cette description estPLEASE AVOID USING TRY-CATCH BLOCKS IN LOOPS

la configuration d'un cadre de pile spécial pour le try / catch ajoute une surcharge supplémentaire, mais la JVM peut être en mesure de détecter le fait que vous revenez et d'optimiser cela.

selon le nombre d'itérations, la différence de performance sera probablement négligeable.

Cependant, je suis d'accord avec les autres pour dire que l'avoir en dehors de la boucle rend le corps de la boucle plus propre.

S'il y a une chance que vous souhaitiez un jour continuer le traitement plutôt que de quitter s'il y a un numéro invalide, alors vous voudrez que le code soit à l'intérieur de la boucle.

Si c'est à l'intérieur, vous gagnerez N fois la surcharge de la structure try / catch, par opposition à une seule fois à l'extérieur.

Chaque fois qu'une structure Try / Catch est appelée, cela ajoute une surcharge à l'exécution de la méthode. Juste le petit peu de mémoire et de processeur nécessaires pour gérer la structure. Si vous exécutez une boucle 100 fois, et pour des raisons hypothétiques, disons que le coût est de 1 tick par appel try / catch, alors avoir le Try / Catch à l'intérieur de la boucle vous coûte 100 ticks, par opposition à seulement 1 tick si c'est en dehors de la boucle.

Le but des exceptions est d'encourager le premier style: laisser la gestion des erreurs être consolidée et traitée une fois, pas immédiatement sur chaque site d'erreur possible.

mets le dedans. Vous pouvez continuer le traitement (si vous le souhaitez) ou vous pouvez lancer une exception utile qui indique au client la valeur de myString et l'index du tableau contenant la mauvaise valeur. Je pense que NumberFormatException vous indiquera déjà la mauvaise valeur mais le principe est de placer toutes les données utiles dans les exceptions que vous lancez. Pensez à ce qui vous intéresserait dans le débogueur à ce stade du programme.

Considérer:

try {
   // parse
} catch (NumberFormatException nfe){
   throw new RuntimeException("Could not parse as a Float: [" + myString + 
                              "] found at index: " + i, nfe);
} 

En cas de besoin, vous apprécierez vraiment une exception comme celle-ci avec autant d'informations que possible.

J'aime ajouter le mien à 0.02cpropos de deux considérations concurrentes lorsque je regarde le problème général de l'emplacement de la gestion des exceptions:

1. La responsabilité «plus large» du try-catchbloc (c'est-à-dire en dehors de la boucle dans votre cas) signifie que lorsque vous changez le code ultérieurement, vous pouvez ajouter par erreur une ligne qui est gérée par votre catchbloc existant ; peut-être involontairement. Dans votre cas, c'est moins probable car vous attrapez explicitement unNumberFormatException

2. Plus la responsabilité du try-catchbloc est "étroite" , plus la refactorisation devient difficile. En particulier lorsque (comme dans votre cas) vous exécutez une instruction "non locale" depuis le catchbloc (l' return nullinstruction).

Cela dépend de la gestion des échecs. Si vous voulez simplement ignorer les éléments d'erreur, essayez à l'intérieur:

for(int i = 0; i < max; i++) {
    String myString = ...;
    try {
        float myNum = Float.parseFloat(myString);
        myFloats[i] = myNum;
    } catch (NumberFormatException ex) {
        --i;
    }
}

Dans tous les autres cas, je préférerais essayer à l'extérieur. Le code est plus lisible, il est plus propre. Il serait peut-être préférable de lancer une IllegalArgumentException dans le cas d'erreur à la place si vous renvoyez null.

Je vais mettre mon 0,02 $. Parfois, vous finissez par avoir besoin d'ajouter un "enfin" plus tard dans votre code (car qui a déjà écrit parfaitement son code la première fois?). Dans ces cas, il est tout à coup plus logique d'avoir le try / catch en dehors de la boucle. Par exemple:

try {
    for(int i = 0; i < max; i++) {
        String myString = ...;
        float myNum = Float.parseFloat(myString);
        dbConnection.update("MY_FLOATS","INDEX",i,"VALUE",myNum);
    }
} catch (NumberFormatException ex) {
    return null;
} finally {
    dbConnection.release();  // Always release DB connection, even if transaction fails.
}

Parce que si vous obtenez une erreur, ou non, vous ne voulez libérer votre connexion à la base de données (ou choisir votre type préféré d'autre ressource ...) qu'une seule fois.

Un autre aspect non mentionné dans ce qui précède est le fait que chaque try-catch a un impact sur la pile, ce qui peut avoir des implications pour les méthodes récursives.

Si la méthode "external ()" appelle la méthode "inner ()" (qui peut s'appeler elle-même de manière récursive), essayez si possible de localiser le try-catch dans la méthode "external ()". Un simple exemple de «crash de pile» que nous utilisons dans une classe de performances échoue à environ 6 400 images lorsque le try-catch est dans la méthode interne, et à environ 11 600 lorsqu'il est dans la méthode externe.

Dans le monde réel, cela peut être un problème si vous utilisez le modèle composite et que vous avez de grandes structures imbriquées complexes.

Si vous voulez attraper une exception pour chaque itération, ou vérifier à quelle itération Exception est levée et attraper toutes les exceptions dans une itération, placez try ... catch dans la boucle. Cela ne rompra pas la boucle si une exception se produit et vous pouvez intercepter chaque exception à chaque itération tout au long de la boucle.

Si vous souhaitez interrompre la boucle et examiner l'exception chaque fois qu'elle est lancée, utilisez try ... catch hors de la boucle. Cela rompra la boucle et exécutera des instructions après catch (le cas échéant).

Tout dépend de vos besoins. Je préfère utiliser try ... catch dans la boucle lors du déploiement car, si une exception se produit, les résultats ne sont pas ambigus et la boucle ne se cassera pas et ne s'exécutera pas complètement.