Est-il normal que j'ai parfois l'évier de ma exceptions?

Question

J'ai un meilleures pratiques en question. Je me rends compte c'est subjectif mais je voulais demander à des gens plus intelligents que moi, si ce n'est une commune de la programmation de la pratique.

Si vous avez une méthode de quelque chose de NON-ESSENTIEL que vous ne voulez pas interférer avec l'important fonctionnement de votre application, il est courant d'utiliser une erreur de l'évier comme ça?

Try 
    'do stuff.  not important if it fails.

Catch ex as exception
    'sink.  do nothing.
End Try

Si vous avez pensé de moi et l'embauche de vous l'ont lu certains de mes code et vu ce...voulez-vous?

Seth

MODIFIER Wow! Merci pour vos réponses. Je pense que le consensus est que les ne doit jamais être fait ou ce qu'il doit être très rare.

J'ai pensé que je voudrais vous donner un contexte à cette question. Tout d'abord, j'ai une grande familiarité avec le Karl Paillettes article et ont suivi ce modèle depuis des années.

Mais aujourd'hui, sur le projet sur lequel je travaillais, je travaillais à travers la liste des changements et a été confronté avec l'ajout d'une simple fonctionnalité. (Si vous tenez à le savoir...c'est l'ajout de menu contextuel de soutien à une Riche Zone de Texte.)

La note jointe a dit, "si elle prend plus de 15 minutes...tomber."

Je suis donc face avec l'ajout de ce qui est potentiellement une fonction utile, mais la n'est pas vraiment le temps de tester qu'il ne cassera pas les fonctionnalités. Pour mémoire, notre gestionnaire d'exception pour ce système possède un mécanisme pour la manutention et le naufrage ou l'enregistrement de ces erreurs. Mais si je travaille sur un système qui n'ont pas une solide gestion des erreurs système. Serait-il bon d'ajouter cette fonctionnalité et, si une erreur se produit...rien n'est vraiment perdu.

C'était ma façon de penser. Mais j'ai pris votre message à cœur...que, fondamentalement, c'est une mauvaise idée.

Seth

Answer 1

Oui, c'est courant, mais en général, il ne devrait pas être fait.

Il y a des exceptions comme OutOfMemoryException qui sont les plus pas pris, à moins que vous les attraper pour tenter de mettre fin à votre application normalement.

Dans la majorité des cas, de la déglutition System.Exception ou System.SystemException inévitablement masquer d'autres problèmes d'exécution.

Answer 2

Vous devriez ne jamais cacher Exception. Je peut vous louer de toute façon, mais vous ne pouvez pas le faire que si vous avez travaillé pour moi :)

Sérieusement, si, en Java (par exemple) les Exceptions sont utilisées pour certains cas, vous pouvez choisir de l'ignorer, comme FileNotFoundException (comme vous l'avez fait, avec un commentaire). Mais si jamais vous attraper un type d'Exception-comme IOException -- vous ne pouvez pas le cacher. Si l'Exception ne signifie rien pour vous en particulier, de l'envelopper dans un RuntimeException et de le jeter au client.

Quelque part le long du chemin, Exception doivent être manipulés, mais jamais caché.

Answer 3

Il est commun, mais il est préférable de l'éviter. À tout le moins, vous devez vous connecter à l'exception quelque part.

Aussi, évitez d'utiliser les exceptions pour le contrôle de flux. Votre code doit être écrit pour gérer tout cas sans avoir recours à des exceptions. Outre la performance augmente, cette méthode vous indique également que lorsqu'une exception se produit, il vaut la peine de votre attention.

Answer 4

Vous ne devriez pas être attraper toutes les exceptions ici. Il peut, dans de rares occasions, être d'accord pour ignorer un particulier, attend d'exception. Cependant, attraper toutes les exceptions et de la déglutition signifie que vous essayez de continuer après un OutOfMemoryException et d'autres irrémédiable exceptions

Answer 5

Alors que la plupart des gens ici sont en train de parler du développeur, je tiens à souligner un autre point de vue de l'histoire.

Je l'avoue: j'ai avalé les exceptions et dans tous les cas, c'était parce que mon humble avis le concepteur de la fonction foiré.

"Exceptions" signifie "exceptions", non d'un échec ou d'erreur. Ce que je veux dire, c'est: Si la fonction doit reconnaître que l'entrée ne peut pas être correcte, j'attends que la fonction ne Ne PAS utiliser les exceptions. Ma colère cibles particulièrement "ParseException"s.

Si vous analysez entrée, vous aurez très probablement trouver l'inconnu/corrompu/inexact d'entrée. Que est "normal", pas une exception. Et dans ce cas, je trouve que c'est gênant si le développeur de la fonction throws ParseException si la fonction ne pouvait pas analyser correctement.

Pourquoi ?

• L'exception rompt le flux de contrôle
• L'exception est lent
• Souvent, il n'a pas d'importance de toute façon parce que vous sont en cours d'initialisation avec des valeurs par défaut.

Si vous appelez la parseFunction plusieurs milliers ou des millions(!) de fois vous encombrer de votre fichier de log pour exactement rien.

En revanche, mon idéal de la fonction renvoie un objet de classe avec le code d'état, et message du genre

StatCode stat = parseXYZ(Reader r);

qui peut ensuite être testé.

if (stat.code != OK)  
  //whatever

Si dans l'autre sens, vous êtes confronté à des problèmes qu'on ne peut pas prévoir (fichier n'est pas verrouillé, absurde argument, illégale état du thread) les exceptions sont excellents.