Le problème de la gestion des exceptions est un problème fréquent dans les révisions de code Java. Comme mentionné dans cet article, les règles de base à suivre dans la gestion des exceptions Java ne sont pas si compliquées. Cependant, malheureusement, il est souvent observé que même les programmeurs Java avec de nombreuses années d'expérience de travail ne peuvent pas implémenter une gestion des exceptions appropriée. Sans parler des programmeurs Java moins expérimentés.
Pourquoi la gestion incorrecte des exceptions est-elle si répandue? Trois facteurs principaux peuvent être pris en compte. Premièrement, il existe une confusion historique dans le mécanisme d'exception (en particulier les exceptions vérifiées) dans la spécification du langage Java, ce qui donne aux programmeurs une liberté excessive. Deuxièmement, à moins que vous ne développiez non seulement l'application, mais que vous l'utilisiez également, vous ne devriez pas remarquer les effets néfastes d'une gestion inappropriée des exceptions. Enfin, il n'existe pas de collection compacte de ressources pour apprendre à gérer correctement les exceptions. Dans les livres pour débutants, la gestion des exceptions ad hoc qui provoque ʻe.printStackTrace () ʻest évidente, et les méthodes de gestion des exceptions appropriées sont dispersées dans les livres et les documents de base pour les utilisateurs intermédiaires et supérieurs.
Par conséquent, dans cet article, nous le diviserons en trois étapes pour les débutants, les débutants et les intermédiaires, comment éviter le piège d'une liberté excessive de gestion des exceptions et quelle est la gestion des exceptions appropriée du point de vue de l'opération. Je voudrais le rendre compact. L'application cible est principalement supposée être du côté serveur (bien que de nombreux éléments ne devraient pas s'appliquer uniquement du côté serveur).
Voici quelques éléments à comprendre avant de vous rendre sur les lieux.
Il y a un gros problème avec ce code, qui exprime un système anormal d'appels de méthode avec une valeur de retour spéciale. Premièrement, l'appelant de createItem () peut oublier d'implémenter un traitement anormal. De plus, l'appelant ne sait pas ce qui n'allait pas, sachant simplement que la valeur de retour est vide.
Item item = createItem();
if (item == null) {
//Système anormal
...
} else {
//Système normal
...
}
Avec l'introduction du mécanisme d'exception, le code peut être réécrit comme suit: En conséquence, l'appelant peut être guidé pour implémenter explicitement le traitement anormal. En outre, l'appelant peut saisir les détails de l'anomalie à partir du message d'exception et de la trace de pile interceptée dans la clause catch.
try {
Item item = createItem();
//Système normal
...
} catch (ItemCreationException e) {
//Système anormal
...
}
Si vous utilisez le mécanisme d'exception, vous pouvez simplement traiter des systèmes anormaux, même dans une hiérarchie d'appels à plusieurs étapes. Par exemple, les applications avec une architecture en couches typique ont tendance à avoir cette hiérarchie d'appels à plusieurs niveaux (au niveau débutant, vous n'avez pas à vous soucier des détails si vous trouvez quelque chose de compliqué).
Le problème ici est de savoir comment transporter le système anormal de la couche inférieure vers la couche supérieure. Par exemple, supposons que lorsqu'une erreur se produit dans l'accès aux données de la couche la plus basse, il soit nécessaire de renvoyer une réponse d'erreur appropriée dans le post-traitement de la couche la plus élevée. Afin de répondre à cette exigence avec une valeur de retour spéciale, une valeur de retour anormale doit être renvoyée de manière relais de compartiment de la couche la plus basse à la couche la plus élevée.
D'autre part, en utilisant un mécanisme d'exception au lieu d'une valeur de retour spéciale, il est possible de gérer une anomalie dans n'importe quelle couche inférieure dans n'importe quelle couche supérieure tout en gardant l'entrée / sortie de la méthode simple. La couche inférieure lance juste une exception comme throw new IllegalStateException (" Quelque chose ne va pas ") sans réfléchir, et une couche supérieure attrape simplement l'exception dans la clause catch.
Vous trouverez ci-dessous un arbre d'héritage de classe d'exception de base (notez que tous les packages sont java.lang). Les exceptions qui héritent de ʻExceptionsont __ exceptions vérifiées __, et les exceptions qui héritent deRuntimeExceptionsont __ exceptions décochées __. Notez queThrowable et ʻError ne nécessitent pas une compréhension détaillée au niveau débutant (plutôt, il vaut mieux ne pas les toucher).
Les exceptions cochées sont des exceptions qui obligent l'appelant à prendre des mesures. Par exemple, si vous écrivez le code qui lit le contenu du fichier comme indiqué ci-dessous, une erreur de compilation sera générée.
List<String> lines = Files.readAllLines(Paths.get("items.csv"));
Error:(x, x) java:Exception java.io.Aucune exception IOException n'est signalée. Doit être capturé ou déclaré lancer
Ici, vous pouvez suivre deux étapes pour terminer la compilation du point de vue d'un débutant. Premièrement, il existe une méthode de capture avec try-catch. Notez qu'il existe de nombreux pièges dans le traitement après la capture ici (les mesures appropriées seront décrites plus loin).
try {
List<String> lines = Files.readAllLines(Paths.get("items.csv"));
//Système normal
...
} catch (IOException e) {
//Système anormal
...
}
Vous pouvez également le laisser explicitement à l'appelant dans la clause throws de la méthode. Cependant, il n'y a pas beaucoup de situations où cette méthode peut être utilisée. Les détails seront décrits dans la section pour les utilisateurs intermédiaires.
public void processItems() throws IOException {
List<String> lines = Files.readAllLines(Paths.get("items.csv"));
//Système normal
...
}
Les exceptions non vérifiées sont des exceptions, telles que les exceptions vérifiées, qui ne sont pas appliquées par l'appelant. Par exemple, la méthode ʻInteger.parseInt (String) peut lever une exception non vérifiée NumberFormatException` (Référence: Javadoc /api/java/lang/Integer.html#parseInt-java.lang.String-)), mais aucune erreur de compilation n'est générée. Au lieu de cela, une erreur se produit au moment de l'exécution.
Integer value = Integer.parseInt("ABC"); //Compilez sans rien faire
java.lang.NumberFormatException: For input string: "ABC"
Maintenant, rappelez-vous ce qu'il faut faire si vous attrapez une exception vérifiée pour la faire passer à travers la compilation, comment l'envelopper dans cette RuntimeException et l'envoyer au niveau débutant. Vous n'avez pas besoin de savoir en détail ce qui arrive aux exceptions non contrôlées que vous lancez au niveau débutant. Ne faites rien de plus.
try {
List<String> lines = Files.readAllLines(Paths.get("items.csv"));
//Système normal
...
} catch (IOException e) {
throw new RuntimeException(e); //Enveloppez dans l'exception non cochée et envoyez
}
RuntimeException Ce serait encore mieux si vous pouviez l'encapsuler dans une exception non cochée appropriée et l'envoyer au lieu de vous concentrer uniquement sur elle. Vous trouverez ci-dessous quelques exceptions non contrôlées couramment utilisées et leurs utilisations très approximatives.
Donc, en fait, le code encapsulé dans le RuntimeException ci-dessus devrait être réécrit pour utiliser ʻUncheckedIOException`.
try {
List<String> lines = Files.readAllLines(Paths.get("items.csv"));
//Système normal
...
} catch (IOException e) {
throw new UncheckedIOException(e); //Enveloppez et envoyez des exceptions non vérifiées plus appropriées
}
Ici, nous décrirons ce que vous devez comprendre lorsque vous développez et opérez sous la direction d'une personne sur le terrain.
Comme mentionné ci-dessus, dans la plupart des cas, vous pouvez écrire du code de sécurité minimale, en vous rappelant simplement de l'envelopper dans une exception non cochée et de l'envoyer. Mais pour une raison quelconque, les programmeurs Java ont tendance à s'écarter de la ligne minimale en faisant des choses supplémentaires ou en oubliant l'essentiel. Voici une gestion des exceptions incorrecte courante. Veuillez ne pas l'imiter.
La première main interdite est l'écrasement. En raison de la compression, un problème se produit dans le traitement ultérieur qui devait donner le résultat correct du traitement qui a été exécuté à l'origine. Un problème typique est «NullPointerException». En général, il y a des occasions où NullPointerException est traité comme un méchant en Java, mais rien ici n'est que votre propre code est mauvais, pas NullPointerException.
List<String> lines = null;
try {
lines = Files.readAllLines(Paths.get("items.csv"));
} catch (IOException e) {
//écraser
}
lines.stream().forEach(...); //J'obtiens une NullPointerException car les lignes sont toujours nulles ici
Cependant, il y a peu de cas qui devraient être écrasés par la volonté. Dans ce cas, il est préférable d'indiquer clairement l'intention dans un journal ou un commentaire.
Le code qui appelle ʻe.printStackTrace () dans la clause catchest souvent vu dans le guide, ce qui est bien, mais c'est presque toujours inacceptable dans les applications Java réelles. J'essaye d'imprimer un message avec ʻe.printStackTrace (), mais si je continue le traitement, ce n'est pas très différent de la compression des exceptions. En outre, la destination de sortie de ʻe.printStackTrace () `est généralement une sortie d'erreur standard, et contrairement aux journaux, les méta-informations telles que la date et l'heure et l'ID de demande qui sont utiles pour rechercher la cause sont manquantes. Si vous laissez ce code sans surveillance, vous serez en proie à une mystérieuse trace de pile que vous ne pouvez pas trouver d'indices à résoudre pendant l'opération.
List<String> lines = null;
try {
lines = Files.readAllLines(Paths.get("items.csv"));
} catch (IOException e) {
e.printStackTrace(); //Désolé pour la sortie de la trace de la pile
}
lines.stream().forEach(...); //Finalement, j'obtiens une NullPointerException ici
Même si le remplacement de ʻe.printStackTrace () () ci-dessus par une sortie de journal, comme log.warn ("Impossible de lire les éléments:" + e, e) `, résout le problème des méta-informations dans la sortie, Il en est de même en ce que si le traitement est poursuivi, il n'est pas très différent de l'écrasement de l'exception.
C'est cette main interdite qu'un débutant méticuleux a tendance à faire. Une fois que le propre journal est sorti individuellement, le journal causé par le même problème est à nouveau généré par le gestionnaire d'exceptions global décrit plus loin. Ceux-ci ressemblent à deux types de journaux d'exceptions pour différents problèmes de fonctionnement et sont source de confusion. Dans le monde adulte, être prudent n'est pas une bonne chose inconditionnellement.
List<String> lines = null;
try {
lines = Files.readAllLines(Paths.get("items.csv"));
} catch (IOException e) {
log.warn("Could not read items: " + e, e); //La minutie se retourne contre lui
throw new UncheckedIOException(e);
}
lines.stream().forEach(...);
Si vous souhaitez inclure un message, envoyez-le en tant que message d'exception.
List<String> lines = null;
try {
lines = Files.readAllLines(Paths.get("items.csv"));
} catch (IOException e) {
throw new UncheckedIOException("Could not read items", e); //Appel nonchalamment
}
lines.stream().forEach(...);
Il y a des erreurs qui oublient le "wrap" de "wrap and send to unchecked exception" et lancent simplement une autre exception non vérifiée. L'effet négatif dans ce cas est que la cause première de l'exception n'est pas connue pendant le fonctionnement. Par exemple, il existe plusieurs causes possibles d'exceptions qui se produisent lors de l'accès à un fichier, telles que le fait que le fichier n'existe pas ou que vous n'avez pas accès au fichier. Si vous oubliez d'envelopper l'exception qui indique la cause première et d'envoyer une autre exception, l'analyse des échecs pendant le fonctionnement devient difficile.
List<String> lines = null;
try {
lines = Files.readAllLines(Paths.get("items.csv"));
} catch (IOException e) {
throw new IllegalStateException("Could not read items"); //Les informations qui auraient dû figurer dans l'exception d'origine sont perdues
}
lines.stream().forEach(...);
Lorsqu'un processus ouvert pour une ressource telle qu'une connexion de fichier ou de base de données est exécuté, le processus de fermeture doit être effectué après cela en principe (si le processus de fermeture est strictement requis est déterminé en se référant au Javadoc de la méthode de processus ouvert. chose). Un effet indésirable courant de l'oubli de fermer est la soi-disant fuite de mémoire. Cependant, dans de nombreux cas, le problème n'est pas découvert immédiatement après la libération, et il devient apparent comme une bombe chronométrée avec l'opération suivante. Une fois découvert, le site sera épuisé par des opérations provisoires telles que la recherche du criminel et le redémarrage régulier.
try {
BufferedReader in = Files.newBufferedReader(Paths.get("items.csv"));
in.lines().forEach(...);
//dans n'est pas fermé
} catch (IOException e) {
throw new UncheckedIOException(e);
}
Utilisez plutôt la syntaxe try-with-resources.
try (BufferedReader in = Files.newBufferedReader(Paths.get("items.csv"))) {
in.lines().forEach(...);
} catch (IOException e) {
throw new UncheckedIOException(e);
}
Avant l'introduction de la syntaxe try-with-resources, le processus de fermeture était effectué dans la clause finally, mais il est redondant et difficile à lire, et il y a beaucoup de choses à prendre en compte lorsqu'une exception se produit dans la clause finally, ce qui est compliqué. Il est prudent de l'éviter au stade du débutant.
BufferedReader in = null;
try {
in = Files.newBufferedReader(Paths.get("items.csv"));
in.lines().forEach(...);
} catch (IOException e) {
throw new UncheckedIOException(e);
} finally {
try {
in.close();
} catch (IOException e) {
throw new UncheckedIOException(e);
}
}
Pour référence, try-with-resources ne peut être utilisé que si la classe cible implémente l'interface java.io.Closeable ou l'interface java.lang.AutoCloseable. Pour plus de détails, reportez-vous aux Documents officiels.
Cette interdiction n'a pratiquement aucun dommage opérationnel, mais il n'est toujours pas bon que le code soit illisible.
try {
Item item = createItem();
//Système normal
...
} catch (ItemCreationException e) {
throw new IllegalStateException(e);
} catch (InvalidProcessingException e) {
throw new IllegalStateException(e);
}
Utilisez plutôt des prises multiples.
try {
Item item = createItem();
//Système normal
...
} catch (ItemCreationException | InvalidProcessingException e) {
throw new IllegalStateException(e);
}
Les exceptions non cochées peuvent également être utilisées pour exprimer de manière défensive des conditions telles que «seuls ces paramètres doivent venir ici» et «ce processus ne doit pas être exécuté».
Une application courante est le lancement de ʻIllegalArgumentException` pour les paramètres invalides dans la clause de garde au début de la méthode.
public void processItem(Item item) {
if (!item.isValid()) {
//Paramètre invalide
throw new IllegalArgumentException("Invalid item: " + item);
}
//Système normal
...
}
Le code ci-dessus est le suivant en utilisant Preconditions de Guava Peut être écrit sur une seule ligne. Je ne peux pas le dire à voix haute, mais si vous n'aimez pas le branchement de niveau «juste au cas» qui réduit la couverture des tests unitaires, c'est une bonne option.
public void processItem(Item item) {
Preconditions.checkArgument(item.isValid(), "Invalid item: %s", item);
//Système normal
...
}
De même, lors de la vérification des paramètres nuls, il est préférable d'utiliser la bibliothèque de classes standard java.util.Objects.requireNonNull (T) au lieu de votre propre instruction if. Au fait, l'exception lancée ici est la tristement célèbre «NullPointerException». La fonctionnalité similaire de Guava, Preconditions.checkNotNull (T), lance également une NullPointerException, ce qui est un peu une résistance. Enroulons-le autour d'un long objet.
public void processItem(Item item) {
Objects.requireNonNull(item, "Item is null");
//Système normal
...
}
En outre, il peut lever une exception dans la partie par défaut normalement inaccessible de l'instruction switch.
Result result = processItem(item);
switch (result) {
case SUCCEEDED:
...
break;
case FAILED:
...
break;
...
default:
throw new IllegalStateException("This would not happen");
}
Jusqu'à présent, nous nous sommes principalement concentrés sur le côté qui lève l'exception, mais nous décrirons ensuite comment gérer l'exception levée.
La manière la plus simple et la plus directe de détecter les exceptions est d'écrire votre propre processus final try-catch en haut de la hiérarchie des appels (méthode principale pour les applications en ligne de commande ou Presentation layer Controller pour les applications Web). Cependant, en réalité, il y a peu de possibilités d'utiliser cette méthode. Dans le développement d'applications Java dans le monde réel, il existe de nombreux cas où la méthode principale est implémentée entièrement, et il existe une meilleure alternative au framework Web pour le contrôleur de niveau Présentation.
Les infrastructures Web modernes fournissent un mécanisme pour exécuter des gestionnaires d'exceptions en fonction de la classe d'exceptions qui se produit. L'avantage d'un tel mécanisme est que le traitement commun de plusieurs contrôleurs peut être combiné de manière flexible sans utiliser la structure d'héritage de la classe Controller. Le mécanisme de gestion des exceptions dans une infrastructure Web typique est illustré ci-dessous.
Un mécanisme plus général est le mécanisme d'intercepteur de conteneur DI. Vous pouvez utiliser le mécanisme Interceptor pour insérer un prétraitement et un post-traitement pour tout appel de méthode dans une classe sous le contrôle d'un conteneur DI. Le mécanisme de l'Interceptor dans un conteneur DI typique est illustré ci-dessous.
Le traitement typique réalisé à l'aide du mécanisme Interceptor pour les exceptions est le contrôle des transactions (annule automatiquement lorsqu'une exception se produit sous une méthode spécifique). Le mécanisme de contrôle des transactions dans un conteneur DI typique est illustré ci-dessous.
Lorsque vous pouvez gérer les exceptions globalement en fonction de la classe, vous souhaitez créer vos propres exceptions. Par exemple, vous souhaiterez peut-être renvoyer une réponse d'erreur personnalisée spécifique à une logique métier particulière ou à une logique d'accès API externe. Pour créer votre propre exception, vous pouvez hériter de la classe d'exceptions existante et remplacer le constructeur.
public class ItemCreationException extends RuntimeException {
public ItemCreationException() {
}
public ItemCreationException(String message) {
super(message);
}
public ItemCreationException(Throwable cause) {
super(cause);
}
public ItemCreationException(String message, Throwable cause) {
super(message, cause);
}
public ItemCreationException(String message, Throwable cause, boolean enableSuppression,
boolean writableStackTrace) {
super(message, cause, enableSuppression, writableStackTrace);
}
}
À première vue, la quantité de code peut sembler importante, mais le travail est mineur car il est en fait généré par l'EDI. Par exemple, dans le cas d'Eclipse, dans la boîte de dialogue de nouvelle génération de classe, spécifiez simplement le nom de la super classe et vérifiez la génération du générateur.
Ici, nous décrirons ce que vous devez comprendre lors du développement et de l'exploitation sur le terrain à votre propre discrétion.
Pour les exceptions gérées par le gestionnaire d'exceptions global, il est nécessaire de générer un journal à un niveau approprié et d'effectuer des opérations quotidiennes. Ce qui suit est un exemple de la politique concernant l'utilisation appropriée des niveaux et du fonctionnement. Ceci n'est qu'un exemple et chaque équipe a des politiques différentes.
Cependant, il est généralement difficile d'appliquer strictement les règles immédiatement après la sortie, et en réalité, les opérations ci-dessus seront développées étape par étape en coupant la phase.
Les applications Java réelles peuvent nécessiter une gestion des exceptions spécifique à une fonctionnalité plutôt qu'une gestion globale des exceptions. Les cas suivants sont des exemples typiques.
Lorsqu'il n'est pas approprié par conception que la couche inférieure lève une exception, elle peut intercepter l'exception et renvoyer une autre valeur de retour. Par exemple, le code suivant intercepte une exception indiquant que l'enregistrement n'existe pas lors de l'accès à la base de données, et renvoie à la place une valeur de retour «Facultatif».
public Optional<Item> findByName(String name) {
try {
Item item = entityManager.createQuery("...", Item.class).setParameter(1, name).getSingleResult();
return Optional.of(item);
} catch (NoResultException e) {
return Optional.empty();
}
}
Notez que vous ne devez pas choisir une conception qui renvoie null au lieu de Facultatif. Voir Résultats de recherche Twitter pour "null kill" pour plus de détails. ..
Lors d'un traitement tel qu'un appel d'API externe, une exception indiquant une erreur de communication accidentelle peut être interceptée et un traitement de nouvelle tentative peut être exécuté. Cependant, lorsque vous essayez d'implémenter sérieusement le traitement des nouvelles tentatives, il y a étonnamment de nombreux éléments à prendre en compte, tels que le paramètre de délai d'expiration, le paramètre de nombre de tentatives, l'algorithme d'interruption, la gestion de l'occurrence de nouvelles tentatives simultanées, la surveillance de l'état des nouvelles tentatives, etc. Plutôt que de l'implémenter vous-même, Microprofile Retry et [Spring Retry](https :: Il serait plus sûr d'utiliser une bibliothèque comme //github.com/spring-projects/spring-retry). À l'avenir, on s'attend à ce qu'une telle logique soit reprise par des mécanismes de Service Mesh tels que Istio en dehors de l'application.
De plus, un traitement alternatif peut être effectué selon les exigences. Le contenu du traitement étant au cas par cas, les détails sont omis.
Enfin, j'expliquerai comment utiliser les exceptions vérifiées que j'ai évitées jusqu'à présent.
Premièrement, pour les bibliothèques et frameworks de bas niveau, il y a des occasions où la vérification des exceptions doit être utilisée de manière appropriée, comme c'est le cas avec le paquet java.io.
En outre, pour la logique métier, si vous souhaitez forcer l'appelant à traiter les systèmes anormaux, l'utilisation d'une exception de vérification est une option. Voici un exemple de méthode qui utilise une exception vérifiée et une méthode qui renvoie une énumération. La méthode utilisant des exceptions vérifiées a une signature de méthode simple, et un traitement similaire peut être partagé en utilisant la structure d'héritage d'exceptions. D'autre part, dans la méthode de retour avec enum, il est facile de comprendre que l'appelant gère la valeur de retour de manière exhaustive. Lequel choisir est au cas par cas.
public void sendNotification(Member member, Notification notification) throws InvalidMemberException {
//Méthode utilisant une exception de contrôle
...
}
try {
sendNotification(member, notification);
//Système normal
...
} catch (InvalidMemberException e) {
//Traitement alternatif
...
}
public NotificationResult sendNotification(Member member, Notification notification) {
//Méthode à retourner avec enum
...
}
NotificationResult result = sendNotification(member, notification);
switch (result) {
case SUCCEEDED:
//Système normal
...
break;
case INVALID_MEMBER:
//Traitement alternatif
...
break;
...
}
Jusqu'à présent, nous avons montré ce que vous devez comprendre sur la gestion des exceptions dans les applications Java réelles en trois étapes: débutants, débutants et intermédiaires. Nous espérons que cet article réduira autant que possible les révisions de code improductives et les opérations applicatives douloureuses.
Recommended Posts