[JAVA] Le silence d'exception est le pire (pourquoi le programmeur fait taire l'exception?)

Introduction, le but de ce document

--Le flux est d'éradiquer catch (Exception e) {} et d'écrire le poème qui suit.

Comportement d'un programmeur

―― "Ah, c'est une exception. Cela ne se produit pas, donc je ne suis pas sûr, donc vous pouvez simplement le tuer. Catch (Exception e) {} est OK." «C'est le pire.

Changeons notre position et réfléchissons-y.

Que se passe-t-il si vous faites taire l'exception?

Pourquoi le programmeur (utilisateur) tue-t-il silencieusement l'exception?

―― Les exceptions gérées par la conception sont gérées correctement, n'est-ce pas? (Nouvelle tentative d'erreur de communication) ―― Le problème est de savoir comment gérer les exceptions qui ne sont pas décidées par conception. Par conséquent, le programmeur choisit "Le traitement n'a pas été décidé -> La mise à mort silencieuse est correcte".

Alors, que devons-nous faire avec des exceptions indécises?

―― Laissons "l'exception qui n'a pas été décidée pour gérer → catch and throw tel quel". ――C'est la bonne réponse.

Pour ceux qui se demandaient: "Quoi? Puis-je lancer une exception que je ne comprends pas?"

«En premier lieu, les exceptions qui ne sont pas gérées par conception sont des exceptions extrêmement rares. (Il n'y a pas de design car il est pratiquement impossible de se produire) «Donc ça n'arrive presque jamais. Donc, que vous tuiez ou jetiez silencieusement, le code n'est pas réellement exécuté, donc dans ce sens c'est le même, peu importe celui que vous choisissez. IfMais si vous choisissez l'un ou l'autre, le lancer est meilleur que le meurtre silencieux si vous pensez à * si cela arrive *. (Cependant, quand cela arrivera vraiment, ce sera l'allié le plus puissant)

À ceux qui pensaient: "C'est une exception très rare, et si cela n'arrive presque jamais, vous pouvez le tuer en silence."

«Je pense que cela ne se produira presque jamais maintenant, mais quand il entre en phase d'exploitation, cela se produit soudainement.

À ceux qui pensaient: "Non, savez-vous ce que signifie lancer une exception? Le système s'arrêtera? Je n'ai pas le courage d'écrire une chose aussi effrayante."

Pour ceux qui se demandaient: "Non, comment concevez-vous une exception très rare?"

――Par exemple, que diriez-vous de dire "Attrapez une exception très rare dans la classe supérieure, enregistrez-la comme ERREUR et continuez le système"? ――Voyez, vous pouvez lancer des exceptions très rares en toute tranquillité d'esprit.

Pour ceux qui pensaient: "Non, même si une exception très rare s'est produite, c'est un problème avec une conception aussi bâclée de cracher des journaux et de continuer le système."

Pour ceux qui pensaient: "Non, même avec des exceptions extrêmement rares, la cause peut être comprise? C'est un problème si vous ne la concevez pas correctement."

«C'est super rare, n'est-ce pas? Cela ne se produit généralement pas, non? Concevez-vous vraiment? ――Vous ne pouvez pas simplement le concevoir, non? Cela augmentera le nombre de personnel pour le montage, les tests et l'utilisation, n'est-ce pas? «Ce n'est pas rentable, n'est-ce pas? Êtes-vous prêt à le supporter? ――Alors, tu le fais vraiment?

Recommended Posts

Le silence d'exception est le pire (pourquoi le programmeur fait taire l'exception?)
A quoi sert le constructeur?
Spring Autowired est écrit dans le constructeur
Qu'est-ce que JSP? ~ Connaissons les bases de JSP !! ~
Le silence d'exception est le pire (pourquoi le programmeur fait taire l'exception?)
Pourquoi la méthode get est nécessaire dans la classe Calendar