Dev Faq
11
votes

Quelle est la meilleure pratique pour essayer des blocs de capture pour créer un code propre?

Duplicaté possible:

meilleures pratiques pour la gestion des exceptions en Java ou C # < / p>

J'ai lu Une question plus tôt aujourd'hui sur Stackoverflow et cela m'a fait penser à propos de quelle est la meilleure pratique pour la manipulation des exceptions.

Donc, ma question est Quelle est la meilleure pratique à gérer des exceptions à Code propre et de haute qualité .

Voici mon code, je pense que c'est calme tout de suite, mais s'il vous plaît laissez-moi savoir si je me trompe ou pas clair! J'ai essayé de garder à l'esprit le testabilité et le même niveau d'abstraction dans les méthodes.

Chaque commentaire constructif est accueilli. :) xxx

édité:

Ce que je veux éviter, c'est écrire beaucoup d'étuis de capture après l'autre ...

3 commentaires

@XScape: Je vais certainement le lire, merci.

À titre de note latérale, je vous recommanderais de marquer vos méthodes d'aide privées statique , comme c'est ce qu'elles sont: elles prennent des intrants et produisent des sorties uniquement sur la base de ces intrants. Quand je n'ai vu aucun statique de votre déclaration de méthode, j'ai été obligé de vérifier si les méthodes n'utilisaient vraiment aucun état, ce qui est mauvais, car le code me force à se concentrer sur quelque chose qui n'est pas important du tout. pour le lire. Cette question concerne que: Stackoverflow. com / questions / 3346764 / ...

@Bruno Reis: Merci, je vais le lire.

4 Réponses :

3
votes

Pour des exceptions vérifiées que je ne vais pas déranger, j'utilise toujours org.apache.commons.lang.unhandleXception.

Par exemple P> 

/**
 * Calls Thread.sleep(millis)
 */
public static void threadSleep(final long millis) {
    try {
        Thread.sleep(millis);
    } catch (final InterruptedException e) {
        throw new UnhandledException(e);
    }
}

0 commentaires
5
votes

Quelques suggestions à première vue:

  1. Vous ne devriez pas attraper jetable et plutôt attraper comme spécifique d'une exception que possible. Le problème avec l'attrape jetable est celui-ci inclura des classes comme comme OutofMemoryError Et similaire. Vous voulez laisser ces traverser (ils sont décochés pour une raison).
  2. Lorsque vous enregistrez des exceptions toujours passez l'exception et pas seulement son Tostring () . Il est très difficile de diagnostiquer des problèmes sans la trace de la pile.
  3. Vous ne voulez probablement pas de méthode de manutention générale d'exception.

    Ainsi, dans des endroits où vous attrapez des exceptions, vous voulez quelque chose comme ceci: xxx

    Le message doit inclure des informations contextuelles si possible. Tout ce qui pourrait aider à suivre le problème lorsque quelqu'un cherche à travers des grumes.

2 commentaires

Je voulais créer une méthode de manutention d'exception générale. Pourriez-vous m'expliquer pourquoi est-ce une mauvaise pratique? Je veux dire que je peux voir que de cette façon, je peux avaler des exceptions qui ne devraient pas l'être, mais jusqu'à présent, je ne connaissais pas de meilleur moyen de garder la logique commerciale propre. Donc, ce que je n'ai pas voulu voir, c'est d'attraper des cas après l'autre ...

Si vous avez un bloc de code commun que vous souhaitez réutiliser à quelques exceptions près, une méthode générale irait bien. Vous n'avez qu'une ligne dans cette méthode pour le moment cependant, ce n'est donc pas moins de code à la place qui fait l'appel. Si vous conservez, vous devez au moins ajouter une variable de méthode pour réussir le message correspondant. Je ne pense pas que ce soit malpropre d'avoir une journalisation spécifique et une manipulation d'exception spécifique dans votre logique d'entreprise. Si vous vous trouvez en train de répéter le même bloc de code, je l'abstrais (en règle générale).

1
votes

attrape toujours l'exception la plus spécifique possible - sinon jamais attraper jadis.

La chose la plus importante pour moi est que vous n'ayez jamais de bloc de capture vide - l'un d'entre eux peut prendre une quantité de temps incroyable pour trouver si quelque chose à l'intérieur de l'essai jette une exception.

J'aime personnellement supprimer les exceptions vérifiées le plus rapidement possible et les remplacer par des vérifications pré / poster des conditions si possible. Même avec des exceptions décochées à une moindre mesure - toutefois, des exceptions non cochées sont en fait un moyen assez difficile d'indiquer une erreur de programmation comme le contrôle du paramètre pour assurer l'état de l'objet (bien que des affirmations puissent être mieux encore)

3 commentaires

+1 pour ne jamais avoir des blocs de capture vides - et courez PMD / FindBugs pour le chercher

Et si votre enregistreur se jette pendant que vous enregistrez une exception?

Espérons que c'est assez intelligent de signaler que c'est une exception à StDerr avec votre exception enveloppée comme la cause au moins que vous avez quelque chose.

0
votes

Il y a quelques options que vous pouvez choisir.

  1. L'un des adnvantages les plus importants des exceptions utilisant est que vous pouvez avoir le seul gestionnaire d'exception pour tous les cas. Lorsque vous écrivez votre code, vous devriez penser à la fonctionnalité d'abord et que sur la manipulation des exceptions. En conséquence, vous pouvez sauter dans certains endroits essayer / attraper du tout pour des exceptions non cochées et déclarer vos méthodes comme jette SometheckeException pour des exceptions vérifiées. Cela vous permet d'avoir le nombre minimum de gestionnaires d'exception.

  2. Si vous ne savez pas ce que faire exactement avec une exception, retirez-le.

  3. Si vous attrapez une exception vérifiée, mais que vous ne souhaitez pas que vos clients utilisent votre code doivent traiter des exceptions, vous pouvez vérifier la mise à jour des exceptions à décocher. (Hibernate traite des exceptions de cette manière. Ils attrapent une exception SQL cochée et lancent des exceptions non cochées au lieu de cela)
  4. Si la recommandation précédente ne vous convient pas, vous pouvez également choisir des options:
    • Vous pouvez simplement ajouter de la journalisation et de retirhow la même exception
    • Vous pouvez utiliser des chaînes d'exception en lançant une nouvelle exception avec la méthode initCause ()
    • Vous pouvez penser que le code qui invoque votre code ne devrait rien savoir sur l'exception originale, vous pouvez archiver cela en créant une nouvelle exception ou en utilisant la méthode FillinstackTrace ().
    • concernant attraper la jompe. Oui dans les méthodes, vous ne devriez pas l'attraper. Mais en règle générale, le client qui utilise votre programme n'a besoin de ne pas voir des extrémités du tout, par conséquent, vous pouvez attraper un gestionnaire d'exception dans la chaîne.
0 commentaires

Articles qui pourrait vous intéresser :

Comment envoyer une liste vide à la clause IN
Code de réponse 403 inattendu lors de la récupération des données des API
Impossible de trouver la classe UnityPlayerActivity dans com.unity3d.player
Comment définir un tableau dans jsonobject