Pourquoi est-ce une "mauvaise idée" de jeter vos propres exceptions?
10 Réponses :
Ce n'est pas. Vous devriez créer et lancer des exceptions personnalisées chaque fois que vous avez une situation exceptionnelle.
Je pense que vous devriez éviter de créer une exception personnalisée chaque fois qu'il existe une exception appropriée (!) Dans votre langue pour aider les utilisateurs de votre bibliothèque à prendre des conditions exceptionnelles similaires de la même manière.
@DerMike - Une exception personnalisée peut signifier un sous-type de stdt de std :: Exception en C ++ par exemple, ce qui permet au client de s'en occuper de manière unifiée.
@ Dermike, je suis d'accord avec vous, un développement devrait utiliser des exceptions existantes lorsqu'elles s'appliquent.
Ce n'est pas fourni qu'ils sont dérivés de tout type de type d'exception standard de base (STD :: Exception en C ++ ou exception en Python, etc.)
S'ils ne sont pas tirés du type de base normal, les autres peuvent ne pas les attraper lorsqu'elles s'attendent à attraper toutes les exceptions - ce qui serait une mauvaise chose.
Je crois que vous pouvez demander pourquoi est-ce une mauvaise idée de Re-jeter Exceptions.
par "Rethrow", je veux dire attraper une exception et générer un nouveau et le jeter. Cela peut être problématique, car vous pourriez finir de consommer la trace de la pile d'origine et de perdre tout le contexte de l'erreur.
Si vous le faites bien, vous ne le faites pas. En .NET, cela signifie le repousser avec l'instruction retirhow (aucun paramètre)
assez juste. Je ne fais pas .net, donc ceci est en dehors de ma portée mentale. Merci pour l'intéressante Tidbit cependant.
Ce n'est pas une mauvaise idée du tout. Si une situation exceptionnelle se pose, une exception doit être lancée pour le gérer, surtout si vous concevez du code que d'autres peuvent utiliser, peut recevoir une mauvaise entrée, etc.
C'est une mauvaise idée d'utiliser des exceptions où elles ne sont pas absolument nécessaires, telles que des situations recouvrables par des contrôles normales dans le code ou dans le cadre de l'exécution normale, car ils ont beaucoup de frais généraux associés à eux. J'imagine que c'est là que tu as peut-être l'idée d'avoir une mauvaise idée en général. Mais pour ce qu'ils sont destinés à faire (signalant une situation exceptionnelle que votre code n'est pas équipé pour gérer), ils sont absolument le meilleur outil.
Et si vous créez des exceptions personnalisées pour le code, d'autres personnes peuvent utiliser, documentez-vous ce qu'ils sont et ce qu'ils veulent dire. De cette façon, les utilisateurs ultérieurs de votre code sauront qu'ils sont possibles et ce qu'ils veulent dire s'ils surviennent et peuvent les gérer de manière appropriée.
En général, il convient parfaitement à jeter vos propres exceptions. Peut-être que ce que vous voulez vouloir demander était "quand n'est-ce pas nécessairement une bonne idée de jeter ma propre exception?"
Un cas est lorsque vous devriez jeter une exception standard. Par exemple, si votre méthode prend un nom de fichier et est censée renvoyer un fichier, vous devez probablement lancer la standard de votre plate-forme Standard FilenotFoundException au lieu de lancer PeéuTPowersFilenotFoundException. Si vous voulez vraiment jeter votre propre exception, vous devriez probablement l'avoir étendre la standard FilenotFoundException.
Vous ne devez pas inventer votre propre type d'exception, sauf si vous avez quelque chose d'extra, vous souhaitez ajouter au type d'exception.
Si vous souhaitez dire à l'utilisateur de votre API qu'ils ont fourni un argument invalide, vous devez lancer une erreur argument, mais si votre bibliothèque échoue en raison de la raison de la bibliothèque, que vous ne pouvez pas transmettre à une exception régulière, Vous devez rouler la vôtre et laisser contenir l'info que les besoins du développeur.
Il n'est pas faux de créer votre propre type d'exception. Cependant, avant de commencer à créer le vôtre, vous devez vérifier si votre cadre fournit déjà une exception qui convient.
du Directives de conception .NET :
envisager de lancer des exceptions existantes résidant dans les espaces de noms du système Au lieu de créer une exception personnalisée Types.
créer et lancer des exceptions personnalisées Si vous avez une condition d'erreur qui peut être traité de manière programmatique dans un manière différente de tout autre existant exceptions. Sinon, lancez l'un des les exceptions existantes.
Ne pas créer et jeter de nouvelles exceptions juste pour avoir l'exception de votre équipe.
Cela peut être ce que Microsoft a dit lors de la conception de .NET, mais je ne suis pas d'accord. Si un fichier DLL n'est pas trouvé, ce qui serait plus utile: FilenotfoundException ou DLLCouldnTloadException? Ce dernier pourrait utilement à avoir utilement une dllfilenotfoundexception dérivée, mais elle est généralement plus utile de savoir ce que le système essayait de faire quand quelque chose s'est passé, que de savoir quel type d'erreur est survenu.
Continuer la réponse de Peter Un autre cas lorsque jetant une exception n'est pas une bonne idée, c'est si vous utilisez des exceptions de lancer pour contrôler la logique commerciale de votre programme.
Tant que l'exception que vous lancez est dérivée d'un objet approprié et transmet que cette situation exceptionnelle, jetant une exception est totalement acceptable.
Utiliser des exceptions à lancer pour contrôler la logique des entreprises En plus d'être un mauvais modèle de conception a également des conséquences sur la performance - les exceptions de lancement et de capture sont plutôt chères par rapport à la ramification sur la base des résultats renvoyés à partir de la méthode
Il n'y a rien de mal à créer vos propres exceptions, ce qui peut être adapté pour transmettre exactement les informations qui conviennent à votre situation. Un Mais, par tous les moyens, assurez-vous d'attraper et de gérer chaque exception personnalisée à l'intérieur de votre code . Lorsque l'exception volait à un endroit à l'extérieur de votre module (appelez le package informatique, appelez l'espace de noms informatique), les personnes qui ne savent même pas qu'il existe, beaucoup moins de quoi faire avec elle. Sauf pour un configfilenotfoundexception transmet plus d'informations qu'un FilenotFoundException (quel fichier n'a pas trouvé?).
capture (lancable t) {/ * whut? * /} .
Pour moi, il semble que la question soit à attraper des candidats inexpérimentés essayant de fausses expériences. Il n'y a rien de mal à jeter vos propres exceptions à mon avis et, comme vous pouvez le voir à tous ceux qui ont répondu ici.
Où avez-vous lu ceci?
Ce n'est pas. Qui a dit que c'était?
C'est une très bonne idée de jeter vos propres exceptions! :)
Question d'entretien - Question touristique?
Je pense que cette question est un peu mal formulée.
Cette question sur le lien fourni vous demande de penser à des exceptions et que lorsque les exceptions définies par l'utilisateur peuvent ne pas être appropriées - il est ouvert à ne pas vous demander une réponse définitive oui / non IMO
C'est une question mal fabriquée, sans référence ni détails sur quelle conclusion a soulevé une telle question. Allons-nous voter pour fermer?
Je ne suis pas surpris du tout qu'il provient d'un site de recrutement. Question typique duhuiter ... Tout Bluster, pas de clue.
pourrait une question d'astuce. Mais, plus probablement c'est juste extrêmement mal formulé. Je réfléchirais à deux reprises à propos de rejoindre une entreprise qui pose des questions idiotes comme celle-ci.
Comme d'autres l'ont dit, une question mal formulée