J'ai fait quelques projets jusqu'à présent, et j'ai remarqué que chaque personne que j'ai écrite entièrement sans aucune manipulation d'exception, puis à la fin, je fais beaucoup de tests et les gère tous.
est-ce raison? Je reçois des milliers d'exceptions lors du test (que je répare tout de suite) que si je l'ai géré, je ne verrais pas exactement où il se trouve (lorsqu'il n'utilise pas de points d'arrêt ou l'affichant nulle part ... mais cela ne semble pas aussi pratique) Je fixe donc des problèmes en vérifiant toutes les exceptions, puis à la fin, je les manipulez de toute façon pour toute éventuelle qui aurait pu être échappée (bien sûr).
Et toi? Quand les gars-là prennent soin d'exceptions?
9 Réponses :
Je dirais que cela est en arrière (mais commun).
Vous voudrez peut-être examiner le développement dirigé par des tests et tester la première conception
Astuce: Pensez à un comportement, écrivez le code pour le tester, ajoutez-le à votre application.
Personnellement, je définis toujours un gestionnaire d'exception global non géré adapté au type d'application et que le journal et les exceptions de courrier électronique à mon équipe de Dev. Au cours de l'AQE, nous commencerons ensuite à ajouter une gestion spécifique d'exception aux routines prévisibles (et recouvrables). Dans tous les cas possibles, nous ajoutons un code de programmation défensif afin que des exceptions ne se produisent pas du tout. (Il n'est pas nécessaire de piéger une exception si vous pouvez tester avant d'essayer le code qui pourrait échouer.)
Mes applications ont tendance à se retrouver avec beaucoup de code défensif (qui devrait être construite à partir du début) et seulement une manipulation spécifique d'exception.
Je faisais tout comme ça lors de la programmation. Laissez-moi savoir si je me trompe. Lors de la réception des données d'une source externe, testez si elle est vide avant de l'utiliser, alors l'utilisation des précautions souhaitées est un exemple de code défensif?
Précisément juste, marcelo. Vérifiez si NULL d'un objet avant d'appeler ses méthodes, etc.
Je préfère le développement axé sur les tests. S'il y a une condition d'erreur attendue, puis testez-le pour cela. Si une erreur inattendue augmente, faites-en un test, puis réparez-la.
Je voudrais certainement considérer les exceptions que vous avez lancées lorsque vous développez chaque interface et chaque module.
De cette façon, vous pouvez tester qu'ils sont lancés de manière fiable (lorsque vous attendez et non quand vous ne le faites pas). Les composants consommant ces composants peuvent ensuite être écrits pour être conscients de ces exceptions et de la poignée (ou non au besoin).
Il me semble que vous ignorez certaines fonctionnalités des composants que vous développez. Je vais pratiquement tester toujours pour des fonctionnalités correctes et des circonstances exceptionnelles, pour couvrir autant de scénarios que possible comme tôt que possible.
D'accord. Je préfère documenter (dans les commentaires XML) des exceptions pouvant être lancées par des méthodes lorsque cela est possible.
La réponse à celle-ci est un "ça dépend" très clair.
Vous devez examiner la situation spécifique; Une exception étant-elle lancée dans une pièce de code spécifique où il est possible de récupérer ou de gérer la situation "exceptionnelle", ce qui a été lancé dans l'exception? Dans ce cas, oui, attrapez l'exception et traitez-la à ce niveau.
Par contre, parlez-vous d'erreurs non récupérables? Puis sûr, attrapez-les à un niveau plus global, ou éventuellement pas du tout (c'est-à-dire s'il n'y a rien que vous puissiez faire à propos de l'exception, pourquoi l'attrapez-vous?)
Vous "attrapez-le" afin que vous puissiez tenter de s'échapper de manière responsable, si possible, bien sûr, bien sûr, dans certains cas, la demande peut-elle être trop chaotique un État pour même de tenter.
S'il y a une capacité de «bloquer de manière responsable», je classerais toujours cela comme une situation où la situation exceptionnelle peut être traitée. Cependant, quelque chose comme une exception de mémoire ne peut pas être traité de manière fiable (le code de manipulation pourrait entraîner un même problème), c'est pourquoi je considère qu'une erreur "non récupérable".
La règle de l'endroit où attraper des exceptions est généralement: partout où est l'endroit où vous pouvez les gérer de manière significative.
Parfois, cela dépend de la technologie ou de la plate-forme cible. Je préfère généralement une couche de manipulation d'exception qui prend soin de toutes les exceptions. Chaque bloc de code est à l'intérieur d'un bloc de capture.
La ligne de fin de la ligne est qu'aucune exception ne doit être prise surte par le système d'exploitation ou une autre entité en dehors du programme ou du code.
La beauté des exceptions par rapport aux codes d'erreur de retour d'API est que vous n'avez pas à rechercher des exceptions à chaque couche de votre code. Vous pouvez attraper des exceptions spécifiques pour déterminer des conditions d'erreur spécifiques et peut-être gérer l'erreur ou le réthrow une exception plus appropriée. Vous devez également attraper des exceptions à un niveau élevé dans votre application pour éviter les exceptions non gérées.
Une chose à noter est que, généralement l'utilisateur de l'exception est le développeur et non l'utilisateur final. Plus tard n'apprécie normalement pas les détails techniques des exceptions.
La chose la plus courante que j'ai vue est que les développeurs font un choix conscient quant à ce que le niveau de manipuler des exceptions et de leur permettre d'être jeté. En règle générale, il sera au niveau d'un fil de travail, ou d'un niveau élevé de logique commerciale. Laisser les exceptions se produisent et avoir une méthode de couverture de manipulation / de la journalisation et de la protéger de l'utilisateur.
Le timing est la seule différence entre ce qui se passe généralement et ce que vous faites. Planifiez-le dans vos applications depuis le début et effectuez une manipulation des exceptions à des niveaux élevés.
La fixation des exceptions spécifiques est effectuée via votre méthode de réparer quand c'est un problème. Parfois, une bibliothèque que j'utilise utilisera inutilement des exceptions pour communiquer des informations, et je vais ajouter une exception spécialisée qui manipule tous les appels à cette bibliothèque. Souvent, je le ferai dans une classe wrapper qui masque la mise en œuvre et la gestion des exceptions du reste de ma demande.
Les questions ouvertes doivent être des wikis communautaires. En outre, vous devez préciser clairement si vous avez une langue en tête. Sinon, marquez le langage-agnostique.