Java - Où et comment utiliser des exceptions?

Valeur de retour vs. Jouant une exception

La différence fondamentale entre une exception et une valeur de retour est que la valeur de retour est livrée à votre appelant immédiate, alors qu'une exception est livrée à une clause de capture n'importe où dans la pile d'appels. Cela permet de réutiliser le même gestionnaire d'exception pour de nombreux types d'exceptions différentes. Je vous recommande de favoriser des exceptions sur les codes de retour si et seulement si vous avez besoin de cette fonctionnalité.

Impact de la performance.

Chaque instruction a un effet négatif sur les performances, y compris celles des blocs de captures. . Cependant, tout processeur moderne peut lancer et gérer des millions d'exceptions par seconde, donc si vous ne jetez pas des milliers d'entre eux, vous ne remarquerez rien.

exceptions spécifiques

pour lancer, soyez spécifique pour permettre une manipulation spécifique. Pour la manipulation, vous pouvez être générique, mais vous devez être conscient que des exceptions arbitraires peuvent être livrées à votre gestionnaire, y compris celles non cochées non déclarées par vos callees.

coché

Le débat rage Si des méthodes doivent utiliser des exceptions vérifiées ou non cochées. Jamais juste avaler une exception. Gérer ou retirent-le. Il simplifie la maintenance si vous ne supprimez pas les preuves sur les échecs.

exemple

Une application que j'ai travaillé sur récemment reçoit des commandes sur le réseau qu'il exécute ensuite. Cela implique généralement une interaction supplémentaire avec les systèmes distants, ce qui pourrait échouer pour une foule de raisons. Les méthodes pour effectuer la commande ne captent aucune exception, laissant ainsi la bulle de la pile d'appels au gestionnaire d'exception central de l'auditeur de commandement, qui suit: xxx

Nous n'avons intentionnellement pas attrapé et retire des exceptions dans la logique de traitement, comme nous l'avons estimé que cela aurait ajouté aucune valeur.

SE-Radio a fait un épisode de podcast sur ce sujet de ce sujet de Traitement des erreurs qui explique une certaine philosophie sur la manière d'utiliser des exceptions, ce qui peut être retraité comme "où les absorber".

La principale chose que j'ai retenue est que la plupart des fonctions doivent les laisser buller et la plupart des détails des exceptions doivent se retrouver dans un fichier journal. Ensuite, les fonctions ne réussissent que des messages globaux disant que quelque chose s'est passé.

En un sens, cela conduit à une sorte de hiérarchie d'exception: une pour chaque couche de code.

Comme je pense qu'ils ont dit, il n'a pas de sens d'expliquer à l'utilisateur que ce cluster de DB a échoué car le DNS était indisponible, ou parce que le disque était plein. À ce niveau, quelque chose qui ne pouvait pas permettre de compléter la transaction, c'est tout l'utilisateur doit savoir.

Bien sûr, les développeurs / administrateurs seront heureux de voir plus de détails, c'est pourquoi à la couche de DB, les exceptions spécifiques doivent être enregistrées.

Exception est là pour que le programmeur d'une tâche n'a pas à gérer le problème par lui-même. (1): au cas où le problème ne lui est pas logique de gérer la tâche. Une tâche de lecture d'une chaîne d'un flux ne doit pas gérer l'erreur de disque, n'est-ce pas. Mais il devrait être très logique de gérer si les données ne contiennent pas de chaîne.

(2): il ne peut pas le gérer par lui-même (pas assez d'informations) Une tâche de lecture d'une chaîne d'un fichier et d'un fichier non trouvé peut demander à l'utilisateur de sélectionner un autre fichier, mais comment la tâche peut-il maintenant quel dossier le fichier pourrait être quelle extension le fichier pourrait être. Sans savoir que, comment la tâche peut-elle créer une interface graphique de ré-demandez-la. P>

(3): il n'y a pas de moyen logique (ou gérable) de distinguer entre un retour différent. Si une tâche ne peut pas lire le fichier et renvoyer null. Qu'en est-il de si le fichier dans le mauvais format, renvoyez aussi NULL? Comment ces deux peuvent-ils diffèrent? Des exceptions peuvent être utilisées pour différer cela. C'est pourquoi cela s'appelle une exception :-d. P>

(4): Il existe de nombreuses tâches similaires nécessitant une manipulation et une écriture similaires que dans toutes les tâches sont difficiles à maintenir. Ecrire le code de la poignée pour tous les accès peut être un gâchis car vous pouvez avoir besoin de nombreuses duplications. P>

for(int i = 0; i < Users.length; i++) {
    User aUser = Users[i];
    // Do something with user
}

Replaced with

try {
  for(int i = 0; ; i++) {
      User aUser = Users[i];
      // Do something with user
  }
}
catch(ArrayOutOfBoundException AOBE) {}

Beaucoup de bonnes réponses, laissez-moi simplement ajouter quelques points qui n'ont pas été mentionnés.

1. Vos types d'exception doivent être aussi spécifiques qu'un appelant est susceptible de les distinguer. Par cela, je veux dire, s'il y a deux erreurs possibles, A et B, et tout appelant est susceptible de faire exactement la même chose dans les deux cas, puis faites une seule classe d'exception. Si un appelant est susceptible de faire deux choses différentes, faites deux classes d'exception.

   Pour beaucoup, probablement la plupart des exceptions que je crée, la seule chose que le programme peut effectuer de manière réaliste est d'afficher un message d'erreur et donne à l'utilisateur la possibilité de changer ses entrées et de réessayer. La plupart des erreurs de validation - Format de date non valide, non-chiffres dans un champ numérique, etc --fall dans cette catégorie. Pour ceux-ci, je crée un type d'exception unique, que j'appelle habituellement "BadinputException" ou "validationException", et j'utilise la même classe d'exception dans tout le système. Lorsqu'il y a une erreur, je jette une nouvelle badinputException ("montant ne doit contenir que des chiffres") 'ou d'une autre, puis d'afficher l'appelant et laissez l'utilisateur réessayer.

   D'autre part, si l'appelant est raisonnablement susceptible de faire différentes choses dans différents cas, faites-leur des exceptions différentes.

   règle facile du pouce: Si vous avez deux ou plusieurs exceptions qui sont toujours traitées avec un code identique et dupliqué, combinez-les en une seule exception. Si votre bloc de capture effectue une vérification supplémentaire pour déterminer quel type d'erreur est vraiment, cela aurait dû être deux (ou plus) classes d'exception. J'ai vu du code qui fait exception.getmessage puis cherche des mots-clés dans le message pour déterminer ce que le problème était. Ceci est laid. Faites plusieurs exceptions et faites-la bien.

   2. Il y a trois bonnes raisons d'utiliser des exceptions plutôt que d'autres moyens de manipuler des erreurs.

      (a) Il évite le problème des valeurs de retour "magique", comme une chaîne non nulle est une vraie réponse, mais Null signifie qu'il y avait une erreur. Ou pire, "NF" signifie que le fichier non trouvé, "nv" signifie format invalide, et tout autre est la réponse réelle. Avec des exceptions, une exception est une exception et une valeur de retour est une valeur de retour.

      (b) Les exceptions ignorent parfaitement la ligne principale du code. Habituellement, lorsqu'il y a une erreur, vous voulez sauter un tas de traitement qui n'a pas de sens sans données valides et d'aller à droite pour afficher un message d'erreur et quitter, ou réessayer l'opération, ou tout ce qui est approprié. Dans les mauvaises vieilles matrices, nous écririons "goto panique-avort". Les gotos sont dangereux pour toutes les raisons qui ont été beaucoup discutées. Les exceptions éliminent ce qui était peut-être la dernière raison restante d'utiliser un goto.

      (c) peut-être un corollaire à (b), vous pouvez gérer le problème au niveau approprié. Parfois, lorsqu'une erreur se produit, vous souhaitez réessayer exactement la même fonction - comme une erreur d'E / S peut représenter un problème de communication transitoire. À l'autre extrême, vous pourriez avoir dix niveaux profondément dans les sous-programmes lorsque vous obtenez une erreur qui ne peut être traitée de quelque manière que ce soit de la bombardement de l'ensemble du programme et de l'affichage d'un "désolé, ArmagedDon est survenu, tout le monde ici est mort". Avec des exceptions, il est non seulement facile de choisir le niveau correct, mais vous pouvez faire des choix différents dans différents modules.

S'il vous plaît, ne retournez pas NULL en cas d'erreurs non fatales. Renvoie une nullobject à la place.

Sinon, vous avez besoin d'une vérification nulle après chaque appel à votre code qui est une douleur, et si oublié fera tomber le code.