Pourquoi est-il une « mauvaise idée » de jeter vos propres exceptions?

Question

Pourquoi est-il une « mauvaise idée » de jeter vos propres exceptions?

trouvé ici

Answer 1

En général, il est parfaitement bien de jeter vos propres exceptions. Peut-être ce que vous vouliez poser était « Quand est-il pas nécessairement une bonne idée de jeter ma propre exception? »

Un cas est quand vous devriez jeter une exception standard. Par exemple, si votre méthode prend un nom de fichier et est censé retourner un fichier, vous devriez probablement jeter plutôt que de jeter FileNotFoundException standard de votre plate-forme PeanutPowersFileNotFoundException. Si vous voulez vraiment jeter votre propre exception, vous devriez probablement avoir à prolonger la FileNotFoundException standard.

Mise à jour: Bloch explique dans l'article 60 de

Answer 2

Il est pas. Vous devez créer et lancer des exceptions personnalisées à chaque fois que vous avez une situation exceptionnelle.

Il est pas à condition qu'ils proviennent de quel que soit le type standard d'exception de base est (std :: exception en C ++, ou exception en python, etc ...)

Si elles _aren't_derived du type de base normale, les autres ne peuvent les attraper quand ils attendent d'attraper toutes les exceptions -. Ce qui serait une mauvaise chose

Il n'a pas tort de créer votre propre type d'exception. Cependant, avant de passer par la création de votre propre, vous devez vérifier si votre cadre prévoit déjà une exception qui convient.

De la .Net directives de conception :

  

Pensez à jeter les exceptions existantes   résidant dans les espaces de noms de système   au lieu de créer des exceptions personnalisées   types.

     

Ne créer et lancer des exceptions personnalisées   si vous avez une condition d'erreur   peut être manipulé par programme dans un   autre façon que tout autre existant   exceptions. Sinon, jetez un des   les exceptions existantes.

     

Ne pas créer et lancer de nouvelles exceptions   juste pour avoir l'exception de votre équipe.

Je crois que vous pourriez demander pourquoi est-ce une mauvaise idée de re-jeter exceptions.

Par « rethrow », je veux dire attrapant une exception et que la génération d'un nouveau et de le jeter. Cela peut être problématique, car vous pourriez finir par consommer la trace de la pile d'origine et perdre tout contexte de l'erreur.

Vous ne devriez pas inventer votre propre type d'exception, sauf si vous avez quelque chose supplémentaire que vous voulez ajouter au type d'exception.

Si vous voulez dire à l'utilisateur de votre API qu'ils ont fourni un argument invalide, vous devriez jeter un ArgumentException, mais si votre bibliothèque échoue en raison d'une raison spécifique de la bibliothèque, que vous ne pouvez pas transmettre à une exception régulière, vous devez rouler votre propre et laissez contient les informations les besoins développeur.

Pour continuer la réponse de Pierre un autre cas, en lançant une exception est pas une bonne idée si vous utilisez lancer des exceptions pour contrôler la logique métier de votre programme.

Tant que l'exception vous lancer est dérivé d'un objet propre, et transmet juste que -. Situation exceptionnelle, lancer une exception est tout à fait acceptable

Utilisation de lancer des exceptions pour contrôler la logique métier en plus d'être un mauvais modèle de conception a également des implications de performance - lancer et à attraper des exceptions est assez cher par rapport à la ramification sur la base des résultats renvoyés par la méthode

Il n'y a rien de mal à créer vos propres exceptions, qui peuvent être adaptés pour transmettre exactement les informations qui convient à votre situation. Un ConfigFileNotFoundException transporte plus d'informations qu'un FileNotFoundException (quel fichier ne trouvons-nous pas?).

Mais, par tous les moyens, assurez-vous que vous attraper et gérer chaque exception personnalisée dans de votre code . Lorsque l'exception vole à un endroit en dehors de votre module (appeler l'emballage, l'appeler espace de noms), ces gens là-bas ne savent même pas qu'il existe, beaucoup moins ce qu'il faut faire avec elle. À l'exception d'un catch (Throwable t) {/* whut? */}.

Pour moi, il semble que la question est d'attirer des candidats inexpérimentés essayant d'expérience faux. Il n'y a rien de mal à jeter vos propres exceptions à mon avis, et que vous pouvez voir à tout le monde qui a répondu ici.

Il est pas une mauvaise idée du tout. Si survient une situation exceptionnelle, une exception doit être jeté à gérer, surtout si vous concevez le code que les autres peuvent utiliser, peuvent recevoir des entrées incorrectes, etc.

Il est une mauvaise idée d'utiliser des exceptions où ils ne sont pas absolument nécessaires, comme des situations qui peuvent être recouvrés par des contrôles normaux dans le code ou dans le cadre de l'exécution normale, car ils ont beaucoup de frais généraux qui leur sont associés. J'imagine que c'est là que vous avez eu l'idée qu'ils sont une mauvaise idée en général. Mais pour ce qu'ils sont censés faire (signalant une situation exceptionnelle que votre code n'est pas équipé pour gérer), ils sont tout à fait le meilleur outil.

Et si vous créez des exceptions personnalisées pour les autres de code pourrait utiliser, ne documentent ce qu'ils sont et ce qu'ils signifient. De cette façon, les utilisateurs plus tard de votre code sauront qu'ils sont possibles et ce qu'ils veulent dire si elles se présentent, et peuvent les traiter de manière appropriée.

Answer 3

Il est pas. Vous devez créer et lancer des exceptions personnalisées à chaque fois que vous avez une situation exceptionnelle.

Answer 4

Il est pas à condition qu'ils proviennent de quel que soit le type standard d'exception de base est (std :: exception en C ++, ou exception en python, etc ...)

Si elles _aren't_derived du type de base normale, les autres ne peuvent les attraper quand ils attendent d'attraper toutes les exceptions -. Ce qui serait une mauvaise chose

Answer 5

Il n'a pas tort de créer votre propre type d'exception. Cependant, avant de passer par la création de votre propre, vous devez vérifier si votre cadre prévoit déjà une exception qui convient.

De la .Net directives de conception :

  

Pensez à jeter les exceptions existantes   résidant dans les espaces de noms de système   au lieu de créer des exceptions personnalisées   types.

     

Ne créer et lancer des exceptions personnalisées   si vous avez une condition d'erreur   peut être manipulé par programme dans un   autre façon que tout autre existant   exceptions. Sinon, jetez un des   les exceptions existantes.

     

Ne pas créer et lancer de nouvelles exceptions   juste pour avoir l'exception de votre équipe.

Answer 6

Je crois que vous pourriez demander pourquoi est-ce une mauvaise idée de re-jeter exceptions.

Par « rethrow », je veux dire attrapant une exception et que la génération d'un nouveau et de le jeter. Cela peut être problématique, car vous pourriez finir par consommer la trace de la pile d'origine et perdre tout contexte de l'erreur.

Answer 7

Vous ne devriez pas inventer votre propre type d'exception, sauf si vous avez quelque chose supplémentaire que vous voulez ajouter au type d'exception.

Si vous voulez dire à l'utilisateur de votre API qu'ils ont fourni un argument invalide, vous devriez jeter un ArgumentException, mais si votre bibliothèque échoue en raison d'une raison spécifique de la bibliothèque, que vous ne pouvez pas transmettre à une exception régulière, vous devez rouler votre propre et laissez contient les informations les besoins développeur.

Answer 8

Pour continuer la réponse de Pierre un autre cas, en lançant une exception est pas une bonne idée si vous utilisez lancer des exceptions pour contrôler la logique métier de votre programme.

Tant que l'exception vous lancer est dérivé d'un objet propre, et transmet juste que -. Situation exceptionnelle, lancer une exception est tout à fait acceptable

Utilisation de lancer des exceptions pour contrôler la logique métier en plus d'être un mauvais modèle de conception a également des implications de performance - lancer et à attraper des exceptions est assez cher par rapport à la ramification sur la base des résultats renvoyés par la méthode

Answer 9

Il n'y a rien de mal à créer vos propres exceptions, qui peuvent être adaptés pour transmettre exactement les informations qui convient à votre situation. Un ConfigFileNotFoundException transporte plus d'informations qu'un FileNotFoundException (quel fichier ne trouvons-nous pas?).

Mais, par tous les moyens, assurez-vous que vous attraper et gérer chaque exception personnalisée dans de votre code . Lorsque l'exception vole à un endroit en dehors de votre module (appeler l'emballage, l'appeler espace de noms), ces gens là-bas ne savent même pas qu'il existe, beaucoup moins ce qu'il faut faire avec elle. À l'exception d'un catch (Throwable t) {/* whut? */}.

Answer 10

Pour moi, il semble que la question est d'attirer des candidats inexpérimentés essayant d'expérience faux. Il n'y a rien de mal à jeter vos propres exceptions à mon avis, et que vous pouvez voir à tout le monde qui a répondu ici.

Answer 11

Il est pas une mauvaise idée du tout. Si survient une situation exceptionnelle, une exception doit être jeté à gérer, surtout si vous concevez le code que les autres peuvent utiliser, peuvent recevoir des entrées incorrectes, etc.

Il est une mauvaise idée d'utiliser des exceptions où ils ne sont pas absolument nécessaires, comme des situations qui peuvent être recouvrés par des contrôles normaux dans le code ou dans le cadre de l'exécution normale, car ils ont beaucoup de frais généraux qui leur sont associés. J'imagine que c'est là que vous avez eu l'idée qu'ils sont une mauvaise idée en général. Mais pour ce qu'ils sont censés faire (signalant une situation exceptionnelle que votre code n'est pas équipé pour gérer), ils sont tout à fait le meilleur outil.

Et si vous créez des exceptions personnalisées pour les autres de code pourrait utiliser, ne documentent ce qu'ils sont et ce qu'ils signifient. De cette façon, les utilisateurs plus tard de votre code sauront qu'ils sont possibles et ce qu'ils veulent dire si elles se présentent, et peuvent les traiter de manière appropriée.