Pourquoi les exceptions vérifiées et non contrôlées sont-elles appelées «la controverse» dans le didacticiel Oracle Java?

Je suis nouveau sur Java et lisais sa documentation sur les exceptions. , et en particulier la page Exceptions non vérifiées - La controverse .

Le résultat net dit:

Si l'on peut raisonnablement s'attendre à ce qu'un client se remette d'une exception, faites-en une exception vérifiée. Si un client ne peut rien faire pour récupérer de l'exception, faites-en une exception non vérifiée.

Je ne comprends pas l'article. De quoi parle la «controverse»? Pouvez-vous l'expliquer en termes simples?

java api-design exceptions

— ABcDexter
source

Duplication possible de Checked vs Unchecked vs No Exception ... Une meilleure pratique de croyances contraires

— gnat

voir aussi: En Java, à quoi servent les exceptions vérifiées?

— gnat

Veuillez voir la question mise à jour, je ne pense pas que ce soit un doublon :)

— ABcDexter

"J'ai essayé de le lire", - que s'est-il passé?

— inutile

Cela s'appelle comme ça parce qu'il y a beaucoup de controverse autour de ce sujet. Voir aussi cette question StackOverflow: Le cas des exceptions vérifiées qui mentionne quelques citations de personnes célèbres / influentes

— Hulk

Réponses:

Je vais vous donner un exemple en premier (mais à la fin, c'est la réponse à la controverse).

Supposons que vous éditez un document dans un éditeur de documents basé sur Java et après avoir terminé, choisissez Fichier-> Enregistrer sous ... et vous avez choisi d'enregistrer le document dans un volume sur lequel vous n'avez pas l'autorisation d'écriture. L'éditeur ne vous écraserait pas avec une trace de pile laide, il vous dirait simplement qu'il ne pouvait pas enregistrer le fichier et il vous permettait de continuer à modifier et / ou à enregistrer à un autre emplacement.

Dans un tel cas, il est probable qu'une exception vérifiée était attendue, interceptée et mise à exécution pour s'en remettre gracieusement.

D'un autre côté, elles supposent une division par zéro ou une exception de pointeur nul causée par une erreur de programmation qui ne pointe sa vilaine tête que dans certaines conditions. Cela peut arriver n'importe où dans le code, la RAM peut être corrompue, etc. Aucun document API ne vous dirait "cette méthode jetterait une division par zéro si la RAM est corrompue" .

Les exceptions vérifiées doivent faire partie de la conception et les utilisateurs de cette API doivent se préparer à les gérer. Des exceptions non contrôlées pourraient se produire presque partout et sont hors de notre contrôle.

La controverse provient du fait que les programmeurs utilisent des exceptions non contrôlées (s'étendant de RuntimeException) lorsqu'ils doivent utiliser des exceptions vérifiées:

comme un raccourci pour ne pas être dérangé par le compilateur
pour rendre leurs signatures plus simples
car ils considèrent que les exceptions vérifiées sont un problème de dépendance (si vous lancez une nouvelle exception vérifiée dans une classe d'implémentation, vous devez modifier la signature de l'interface) et vice versa.

— Tulains Córdova
source

"vous devez modifier la signature de l'interface" - eh bien, vous êtes même obligé de le faire par le compilateur, et vous devrez le gérer ou le déclarer comme étant lancé sur chaque site d'appel.

— Hulk

Le fait qu'une application d'interface utilisateur gère correctement une erreur de manière conviviale dépend de la façon dont le programmeur a écrit le code. Ils peuvent écrire le code très bien de cette façon avec des exceptions non vérifiées, tout comme quelqu'un d'autre peut mal gérer les erreurs avec des exceptions vérifiées. Le but des exceptions vérifiées est de faciliter le traitement correct des erreurs par les programmeurs. La controverse n'est pas ce que vous avez prétendu ici, mais plutôt s'ils réussissent ou non à atteindre cet objectif de faciliter la gestion des erreurs. De l'avis de beaucoup, ce n'est pas le cas; ils le rendent plus difficile.

— Servy

@Servy De quelle manière conviviale une application d'interface utilisateur pourrait-elle gérer le fait d'une puce RAM défaillante, ou se retrouver sans cycle CPU à cause d'un autre logiciel défectueux?

— Tulains Córdova

@ TulainsCórdova Dans l' un de ces cas , le programme ne va même pas à courir , donc il n'y a pas de traitement exception done période , alors comment vous essayez de représenter une erreur est sans objet lorsque vous n'êtes pas en mesure d'exécuter jamais même l' un de vos code quand cela se produit.

— Servy

@ TulainsCórdova Vous ne devez pas nécessairement avoir rencontré l'erreur pour la gérer, mais oui, le compilateur ne vous dira pas qu'elle pourrait être levée. La controverse est de savoir si le compilateur vous dit ou non que l'exception pourrait être levée est réellement utile. Certains pensent que c'est le cas, certains pensent que ce n'est pas le cas. La question ici est de savoir quelle est la controverse , et c'est la réponse. Votre déclaration de ce que la controverse principale des exceptions vérifiées n'est pas.

— Servy

-4

Il n'y a pas de controverse sur cette page. C'est Oracle qui dit aux gens d'utiliser les exceptions vérifiées.

La fausse «controverse» qu'ils ont inventée ici se situe entre les concepteurs de langues et les utilisateurs de langues. Les concepteurs ont permis aux gens de lancer et d'attraper des choses qui (dans leur esprit) ne devraient pas être jetées ou attrapées. Ils ont donc créé une page Web se plaignant des développeurs paresseux.

— ascotan
source

Il y a une controverse même si cette page en dit peu à ce sujet. Ce qui est controversé est la réponse à la question: "Les exceptions vérifiées aident-elles ou entravent-elles le développement de meilleurs logiciels?" Et, "Si oui, quelles exceptions devraient être vérifiées et lesquelles devraient être décochées?" Je parie que vous pourriez entamer une discussion animée si vous aviez suffisamment de développeurs (et de bière) ensemble dans une pièce pour répondre à ces questions.

— Solomon Slow