Règles d'utilisation pour la gestion des exceptions Java

Règlement sur le traitement des exceptions

J'ai résumé les règles que je pense personnellement (ou sont largement suivies) d'essayer, d'attraper et enfin. Si vous avez un autre contenu à protéger, veuillez commenter.

Ne reviens pas avec essayer

enfin est toujours exécuté.

try {
    return 1;
} finally {
    return 2;
}

1. La valeur de retour est 2.
2. «try return» peut être remplacé par «finally return».

essayer / rattraper la boucle

La génération d'exceptions n'est pas gratuite.

pour

int sum = 0;
for (int i = 0; i < 99900000; i++) {
    try {
        sum += i;
    } catch (Exception ex) {
    }
}

pour l'extérieur

int sum = 0;
try {
    for (int i = 0; i < 99900000; i++) {
        sum += i;
    }
} catch (Exception ex) {
}

En raison de la mesure du temps, il y a une différence de performance de 21%. pour: "1312" extérieur: "1042"

Si vous ne désactivez pas JIT (Just In Time), le code sera optimisé et il n'y aura aucune différence. Option invalide JIT: -Djava.compiler = aucun

Remettre l'objet à un état valide avant de lever une exception

L'objet avec l'exception peut continuer à être utilisé.

échantillon

private static class A {
taille maximale int finale privée= 10;
taille actuelle de private int= 0;
    String[] values = new String[20];
    public void add(String val) throws Exception {
La taille actuelle++;
        if (La taille actuelle>Taille maximum) {
            throw new Exception("Dépassé la taille maximale");
        }
        values[La taille actuelle- 1] = val;
    }
}

Code en question

La taille actuelle++;
if (La taille actuelle>Taille maximum) {
    throw new Exception("Dépassé la taille maximale");
}

1. J'ai lancé une exception, mais la taille maximale de cet objet reste «taille maximale + 1».
2. Si vous exécutez values [taille actuelle], cela peut être illégal.

Ne contrôlez pas le processus avec la gestion des exceptions

Les processus qui peuvent être contrôlés par un traitement normal ne doivent pas être traités par exception.

1. Mauvaise lisibilité
2. La gestion des exceptions est coûteuse

Contrôlez le processus avec des exceptions

private static void showWithEx(String[] src) {
    try {
        int i = 0;
        while (true) {
            String s = src[i++];
        }
    } catch (ArrayIndexOutOfBoundsException ex) {
    }
}

Après rénovation

private static void show(String[] src) {
    int i = 0;
    while (i < src.length) {
        String s = src[i++];
    }
}

Mesure des coûts d'exception

python

public static void main(String[] args) {
    final int COUNT = 100000;
    String[] src = {"ab", "cd", "ef"};
    long start = 0L;
    
    start = System.currentTimeMillis();
    for (int i = 0; i < COUNT; i++) {
        showWithEx(src);
    }
    System.out.println(System.currentTimeMillis() - start);

    start = System.currentTimeMillis();
    for (int i = 0; i < COUNT; i++) {
        show(src);
    }
    System.out.println(System.currentTimeMillis() - start);

    start = System.currentTimeMillis();
    for (int i = 0 ; i < COUNT; i++ ) {
        Object o = new ArrayIndexOutOfBoundsException();
    }
    System.out.println(System.currentTimeMillis() - start);
}

production

0
156
63

1. Après la réparation, il était de 0, quel que soit le nombre de réparations.
2. Il en a fallu 156 avant la rénovation
3. new ArrayIndexOutOfBoundsException () est 63, donc les coûts autres que la génération ne peuvent pas être ignorés.

N'utilisez pas un énorme essai

Il est facile de mettre tout le traitement en un seul essai, ce qui est beau et simple à première vue, mais c'est en fait un piège.

1. "Code long = possibilité élevée d'exception", il est donc difficile de déboguer là où l'exception s'est produite
2. Un essai énorme a plus de clauses catch, et ces relations logiques doivent être résolues.

Un énorme essai est NG

public static void main(String[] args) {
    try {
        //Abréviation
        String src;
   
        src = "123";
        int val1 = Integer.parseInt(src);

        src = "abc";
        int val2 = Integer.parseInt(src);
        //Abréviation
        src = null;
        src.getBytes();
    } catch (NumberFormatException ex) {
        System.out.println(ex.getMessage());
    } catch (NullPointerException ex ) {
        System.out.println(ex.getMessage());
    }
}

N'utilisez pas Catch all

Il est NG d'attraper avec une classe d'exception supérieure (Throwable).

1. Seules les mêmes mesures peuvent être prises pour diverses exceptions. Le traitement peut être divisé en utilisant if et instanceOf dans catch, mais ... stop ...
2. Même si le programme doit être arrêté, tel que RuntimeException, il sera intercepté et supprimé sans que personne ne le sache.

N'utilisez pas Catch_all

try {
    // Checked Exception
    File f = new File("n'existe pas");
    int b = new FileInputStream(f).read();
    // Runtime Exception
    Object o = null;
    o.getClass();
} catch (Throwable ex) {
    ex.printStackTrace();
}

Ne cachez pas les exceptions

Si catch, finalement lève une exception, le contenu de l'exception peut être masqué.

public static void main(String[] args) {
    try {
        m1();
    } catch (Exception ex) {
        System.out.println("In main : " + ex.getMessage());
    }
}
private static void m1() throws Exception {
    try {
        System.out.println("m1 : try");
        throw new Exception("First EX");
    } catch (Exception ex) {
        System.out.println("m1 : catch");
        throw new Exception("Second EX");
    } finally {
        System.out.println("m1 : finally");
        throw new Exception("Third EX");
    }
}

production

m1 : try
m1 : catch
m1 : finally
In main : Third EX.

La cause première est throw new Exception (" First EX "); J'ai ramassé un throw new Exception (" Third EX ");.

N'ignorez pas les exceptions

J'ai attrapé une exception, mais "ne rien faire ou ne sortir que le journal" est un travail de dissimulation. Cela a un impact considérable sur la santé du programme.

Ignorer les exceptions

try {
    File f = new File("n'existe pas");
    int b = new FileInputStream(f).read();
} catch (FileNotFoundException ex) {
} catch (IOException ex) {
}

Traitement approprié des exceptions

1. Les exceptions vérifiées doivent être réparées par programme
2. Pour les exceptions irréparables, utilisez les lancers pour demander à l'appelant de réparer

prime

(Régulier) Système de classe d'exception

Classification de classe d'exception

• Runtime Exception
• RuntimeException ou classe héritée
• Exceptions qui semblent irréparables par programme
• Vous n'êtes pas obligé d'attraper
• Checked Exception
• Classes autres que RuntimeException
• Exceptions qui semblent être réparables par programme
• Forcé d'attraper ou de lancer