Introduction aux méthodes de gestion des exceptions Java (avec code)

Cet article vous présente une introduction aux méthodes de gestion des exceptions Java (avec code). Il a une certaine valeur de référence. Les amis dans le besoin peuvent s'y référer.

Avant-propos : Peu importe dans notre travail ou dans notre vie, il y aura toujours diverses "erreurs" et diverses "anomalies" soudaines. Peu importe la préparation et les tests que nous effectuons, ces anomalies apparaîtront toujours à un moment donné. Si elles ne sont pas traitées correctement ou à temps, elles entraîneront souvent de nouveaux problèmes. Par conséquent, nous devons toujours prêter attention à ces pièges et avoir besoin d'un ensemble de « meilleures pratiques » pour établir un mécanisme complet de gestion des exceptions.

Texte

Classification des anomalies

Tout d'abord, j'ai dessiné ici un schéma structurel de classification des anomalies.

Dans le JDK, Throwable est la classe parent de toutes les exceptions, qui est divisée en "Erreur" et "Exception". Erreur signifie qu'une erreur grave et incontrôlable s'est produite, telle que OutOfMemoryError. Les exceptions sont subdivisées en deux catégories. Les exceptions vérifiées (check) nous obligent à essayer/attraper ou lancer manuellement la définition de la méthode. Le compilateur vérifiera sa légalité lors de la compilation. Les exceptions non cochées (décocher) ne nécessitent pas que nous les traitions à l'avance. Ces concepts simples doivent être maîtrisés par les développeurs. Ici, je vais montrer une illustration sans les décrire en détail. Notre "dîner" est encore à venir.

Reconnaître try/catch/finally

En ce qui concerne la gestion des exceptions, try/catch/finally doit être mentionné ici. try ne peut pas exister seul, il doit être associé à catch, enfin, ou aux trois en même temps.
1. Essayez le bloc de code : surveillez l'exécution du bloc de code. Si l'exception correspondante est trouvée, passez au catch. S'il n'y a pas de catch, accédez directement au bloc final.
2. Bloc de code Catch : lorsque l'exception correspondante se produit, le code à l'intérieur sera exécuté, soit géré, soit lancé vers le haut.
3. Enfin le bloc de code : il doit être exécuté qu'il y ait ou non une exception. Il est généralement utilisé pour nettoyer les ressources, libérer les connexions, etc. Cependant, il existe plusieurs situations dans lesquelles le code ici ne sera pas exécuté.

• Le flux d'exécution du code n'entre pas dans le bloc de code try.
• Le code se produit dans une boucle infinie, un blocage et d'autres états dans le bloc de code try.
• L'opération System.exit() est effectuée dans le bloc de code try.

try/catch/finally trap

Voici deux pièges que nous pouvons rencontrer lors de l'utilisation de tcf.

Code 1

public class TCFDemo {
    public static void main(String[] args) {
        //11
        System.out.println(returnVal());
    }

    static int returnVal(){
        int a = 1;
        int b = 10;
        try{
            return ++a;
        }finally {
            return ++b;
        }
    }
}

Piège 1 : Ajoutez une instruction return dans final, qui écrasera la valeur de retour du code try Si la logique métier est complexe, il est facile de tomber. dans un piège ici, ce qui n'est pas propice aux erreurs de dépannage.

Code 2

public class TCFDemo {
    public static void main(String[] args) {
        Lock lock = new ReentrantLock();
       try{
            //有可能加锁失败
            lock.lock();
            //dost
       }finally {
           lock.unlock();
       }
    }
}

Piège 2 : Étant donné que la méthode de verrouillage peut lancer une exception Uncheck lors du verrouillage, si elle se trouve dans un bloc de code d'essai, le déverrouillage sera inévitablement exécuté. À ce stade, puisque le verrouillage n'a pas réussi, une IllegalMonitorStateException sera levée. De cette façon, cette dernière exception écrasera les informations d'exception du précédent échec de verrouillage, nous devons donc déplacer la méthode de verrouillage en dehors du bloc de code try. .

Bonnes pratiques

D'accord, j'ai brièvement présenté la classification des exceptions et les précautions pour try/catch/finally. Quelles sont les « meilleures pratiques » en matière de gestion des exceptions ?

1. Lorsqu'une exception doit être lancée vers le haut, les exceptions ayant une signification commerciale doivent être définies en fonction du scénario commercial actuel, et les exceptions définies au sein du secteur ou celles définies au sein de l'équipe doivent être utilisées en premier. Par exemple, lorsque vous utilisez dubbo pour effectuer un appel de service distant qui expire, DubboTimeoutException sera levée au lieu de lancer directement RuntimeException.
2. N'utilisez pas l'instruction return dans le bloc de code final pour éviter de compliquer le jugement de la valeur de retour.
3. Attrapez la sous-classe spécifique d'exception, pas d'exception, non jetable. Cela détectera toutes les erreurs, y compris les erreurs graves générées par la JVM qui ne peuvent pas être gérées.
4. N'oubliez pas de n'ignorer aucune exception (attrapez-la et ne faites rien). Même si vous pouvez vous assurer que cela n'affecte pas le fonctionnement normal de la logique maintenant, personne ne peut garantir comment le code changera à l'avenir. . Ne ​​le creusez pas pour vous-même.
5. N'utilisez pas d'exceptions comme flux de contrôle. Il s'agit d'une approche très étrange qui affecte également les performances.
6. Les opérations telles que le nettoyage des ressources et la libération des connexions doivent être placées dans le bloc de code final pour éviter les fuites de mémoire. Si la logique traitée par le bloc final est relativement volumineuse et modulaire, nous pouvons l'encapsuler dans des appels de méthode d'outil. , et le code sera plus simple .

Fin

Une petite anomalie a un grand apprentissage, qu'en pensez-vous ?

Ce qui précède est le contenu détaillé de. pour plus d'informations, suivez d'autres articles connexes sur le site Web de PHP en chinois!