Inscrivez-vous gratuitement
pour pouvoir participer, suivre les réponses en temps réel, voter pour les messages, poser vos propres questions et recevoir la newsletter
Vous oubliez que parfois c'est très intrusif de devoir traiter une checked exception obligatoirement alors qu'on est 100% sûr de ne pas la déclencher et quand bien même c'est dans un contexte fatal à l'application. Puis cela encourage parfois à catcher et ne rien faire d'intelligent, ou faire des catch(Exception), ce qui est moins bien que de ne rien faire du tout.
D'ailleurs c'est une particularité de java qui reste l'une des plus controversées.
Encore une fois le mauvais programmeur ne fait pas le mauvais langage. Il y a effectivement un reproche à faire aux exceptions mais certainement pas ça (mais leur coût, ce qui vu la philosophie de C++ justifie amplement que ça ne soit pas obligatoire).Envoyé par _skip
Ca m'intrigue ça, je veux bien savoir par qui.
Chacun son avis, moi je suis la philosophie qu'une exception ne doit pas forcément être gérée et que l'utilisateur doit choisir de la gérer s'il a quelque chose d'intelligent à faire ou s'il anticipe la situation et estime que son application peut raisonnablement poursuivre. Je pense que c'est pas au compilateur de le forcer.Encore une fois le mauvais programmeur ne fait pas le mauvais langage. Il y a effectivement un reproche à faire aux exceptions mais certainement pas ça
Tu n'as qu'à taper "checked exceptions" dans google pour cela. Bonne lecture.Ca m'intrigue ça, je veux bien savoir par qui.
Le C++ et le JAVA ont aussi une philosophie différentes sur les exceptions.
Les exceptions en C++, si elles ne sont pas catchées, remontent automatiquement jusqu'au main() et font s'arrêter le programme si il n'y pas de catch.
Mais avec le système de RAII et de destructeur, il n'y a pas de clause finally(), et aucune obligation de catcher toutes les exceptions.
Ne pas catcher les exceptions dans un programme peut être entièrement correct en C++.
Et ca l'est aussi dans n'importe quel autre langage.
En fait en Java on peut utiliser les deux types d'exception :
- Les checked-exceptions (qui hérite de java.lang.Exception) doivent impérativement être traité par le développeur (c'est à dire soit catché soit remonté à nouveau). C'est généralement très utile pour indiquer des problèmes potentiels aux développeurs, qu'il devra donc traiter (exemple : les IOExceptions lors des traitements sur les entrées/sorties).
- Les unchecked-exceptions (qui hérite de java.lang.RuntimeException) peuvent être remonté sans impliqué de traitement obligatoire. Dans ce cas là comme en C++ elles remonterons jusqu'à la méthode initiale du thread si elle ne sont jamais traité (donc jusqu'au main() pour le thread principal). Elles sont généralement utilisées pour les problèmes liés à un défaut du programme. C'est à dire des erreurs qui généralement ne devrait pas arriver (et donc qui peuvent se permettre de planter le programme). Par exemple les NullPointerException ou encore les ClassCastException.
La polémique vient du fait que les checked-exceptions sont peut-être un peu trop utilisées, et ce même dans l'API standard, alors que les unchecked-exceptions ont également leurs avantages du fait qu'il reste possible de les ignorer selon les cas : le développeur n'est pas forcé de les traiter !
Le meilleur exemple concerne la lecture de donnée. Par exemple prenons ces deux lignes de code :
La première ligne provoquera une erreur de compilation, car la check-exception MalformedURLException n'est pas traité !
Code : Sélectionner tout - Visualiser dans une fenêtre à part
2
3URL url = new URL("http://www.google.fr/"); // MalformedURLException Integer integer = Integer.parseInt("12345"); // NumberFormatException
A l'inverse, la seconde ligne compilera sans erreur, mais génèrera une unchecked-exception (NumberFormatException) si la chaine est incorrect.
Selon la provenance des données on peut vouloir un comportement différent. Or les checked-exceptions ne permettent pas cela.
Bien sûr si les données proviennent d'une saisie utilisateur il faudra impérativement les traiter dans les deux cas. Mais si les données viennent d'un fichier de config ou de valeur "en dur" dans le code on peut les considérer comme correcte, et alors la checked-exception nous embêtes car il est obligatoire de la traiter.
Du coup le problème c'est que bien souvent cela se traduit par un traitement qui ignore complètement l'exception, ce qui est bien pire qu'un unchecked-exception :
Code : Sélectionner tout - Visualiser dans une fenêtre à part
2
3
4
5
6URL url = null; try { new URL("http://www.google.fr/"); } catch (MalformedURLException e) { // On ignore car ca n'arrive jamais ! }
Bien sûr il faut quand même relativiser cela, car la solution consiste à transformer l'exception en unchecked au lieu de l'ignorer. Pour cela on peut tout simplement se contenter de l'englober dans une unchecked-exception :
Code : Sélectionner tout - Visualiser dans une fenêtre à part
2
3
4
5
6
7
8URL url = null; try { new URL("http://www.google.fr/"); } catch (MalformedURLException e) { // cela ne devrait pas arriver, // mais au cas où on plante le programme : throw new RuntimeException(e); }
a++
Merci pour cet exposé fort complet AdiGuba. De mon point de vue ça confirme ce que je disais : il s'agit encore une fois de bonne pratique et de ce qui est mon leitmotiv "le mauvais programmeur ne fait pas le mauvais langage"...
Surtout que le commentaire "ça ne devrait pas arriver" dénote une capacité à lire l'avenir (l'évolution de son code et toutes les utilisations qui en seront faîtes) chez le programmeur qui est assez impressionnante !
Je dis ça mais je crois que j'en ai encore un ou deux de cet acabit qui traînent, il faut que j'aille leur faire un sort
En fait la "polémique" sur les checked-excpetions vient du fait qu'en obligeant à les traiter, on se retrouve souvent avec un mauvais traitement qui est bien pire qu'aucun traitement sur une unchecked !
a++
Lorsqu'on rencontre des situations ou on ne peut rien faire face à une checked exception, on est presque obligé de les encapsuler dans une RTE comme a dit Adiguba, même si on a pris toutes les mesures pour les empêcher d'arriver.
Personnellement je ne peux me permettre de juste les ignorer....
Le problème de cette encapsulation, c'est qu'on peut dans certaines situations se retrouver à dupliquer des méthodes juste pour *supprimer* une checked exception car on ne veut pas se la déclarer entre les multiples appels, sachant qu'elle aura tout perdu de son sens une fois arrivée au sommet.
En bref elle ne ferait qu'introduire du couplage entre les appels.
Ca pousse à créer son "framework dans le framework" qui est parfois juste de la plomberie qui apporte presque rien, juste dans le but de stopper des erreurs qui sont de toutes façons impossibles, ingérables et irrécupérables.
La seule chose que java force le développeur a faire, c'est que s'il ne désire pas catcher une checked exception il doit indiquer qu'il la renvoit. C'est une manière explicite de faire les choses qui a un avantage, c'est d'être sur de ne pas en oublier, car sinon ton soft va très bien marcher et le jour ou un problème se produit au lieu de traiter le problème et de continuer il va s'arrêter comme une m*** parce qu'il est survenu un truc imprévu
Ca me dérange pas qu'il plante comme une merde, j'aime 1000 fois mieux ça plutôt qu'il continue à s'exécuter comme un con dans un état imprévu. Mais il me semble que c'est pas ce que tu veux dire.La seule chose que java force le développeur a faire, c'est que s'il ne désire pas catcher une checked exception il doit indiquer qu'il la renvoit. C'est une manière explicite de faire les choses qui a un avantage, c'est d'être sur de ne pas en oublier, car sinon ton soft va très bien marcher et le jour ou un problème se produit au lieu de traiter le problème et de continuer il va s'arrêter comme une m*** parce qu'il est survenu un truc imprévu
Je reconnais que ça a l'avantage signalétique pour ceux qui se donnent pas la peine de lire la doc d'une fonction ou qui introduisent des breaking changes en faisant évoluer du code existant. Cependant je maintiens que c'est pénible de décorer 20 méthodes d'un throws MonException parce que la 21e fait un throw MonException dans des situations irrécupérables, voire même pas plausibles.
Ca encourage les gens à faire des choses stupides (sans les en obliger, soyons d'accord) comme mettre des throws Exception partout ou faire des catch vides, cependant on parle là d'une faute du développeur.
Plus particulièrement, lorsque tu disposes déjà d'une API de haut niveau qui par malheur signale des checked exceptions ingérables, t'es obligé de mettre ta propre couche par devant qui ne fait qu'encapsuler ces checked exceptions dans des RTE, de la plomberie pure quoi.
Par ailleurs ça empêche aussi ce genre de chose :
qui permet de généraliser un code de gestion d'exception sans passer par une méthode privée spécifique à laquelle il faudrait passer en paramètre des éléments du contexte de la méthode qui déclenche l'exception.
Code : Sélectionner tout - Visualiser dans une fenêtre à part
2
3
4
5
6
7
8
9
10
11try { ..... } catch ( Exception ex) { if( ! (ex instanceOf ExceptionA || ex instanceOf ExceptionB || ...)) throw ex; (...) //code de gestion d'exception identique pour ExceptionA, B, C etc... }
Mais heureusement on a de bonnes chances d'avoir une syntaxe qui résoudra ce problème dans Java 7. C'est sauf erreur parmi les nouveautés les plus attendues.
Eh bien la doc c'est toujours l'argument qui revient, sauf que la doc par expérience n'est jamais complète ni parfaite, surtout si une fonction appelle une fonction qui en appelle une autre.
Pourquoi tes fonctions tu leur donne des paramètres typés et pas que des void*, après tout ils ont qu'a lire la doc pour savoir ce qu'il faut mettre.
Pour ton exemple de décorer la 21 ème couche d'appel avec un throws XXXException, effectivement c'est chiant, mais si tu ne le fais pas, celui qui appelle ta fonction ne saura pas qu'elle peut survenir (a moins que tu le mette dans la doc de tes 21 fonctions successives et dans ce cas c'est exactement comme déclarer un throws sauf qu'on perd les avantages qu'apportent une checked exception), et donc personne ne la catchera, elle arrivera au main() et ton soft plante.
Sinon pour ton cas
il est un peu crado honnêtement, et si tu as un code identique pour plusieurs exceptions, ben c'est le moment d'utiliser une fonction non ?
Code : Sélectionner tout - Visualiser dans une fenêtre à part
2
3
4
5
6catch (Exception ex) { if( ! (ex instanceOf ExceptionA || ex instanceOf ExceptionB || ...)) throw ex; // code identique pour les autres }
C'est pas une syntaxe si crade que ça, ça se voit beaucoup en C#.
Je trouve ça plus clean que de créer une fonction B à laquelle je dois passer tout le contexte et les variables locales de ma fonction A. Si j'ai 10 méthodes dans ma classe qui chacune demande sa propre méthode de gestions d'exceptions je m'en sors plus. A ce moment là autant faire des blocs catch multiples et des copier-collers.
Pour la doc je suis d'accord que c'est de toutes façons un problème, mais si c'est une checked exception raisonnable c'est inévitable. Je parle surtout de checked exceptions impossibles ou moins qu'improbables qu'on choisirait naturellement de ne pas catcher faute de savoir qu'en faire et que le compilateur nous oblige à traiter.
Et dans les deux cas, les tests unitaires peuvent aussi aider.
Ca n'a absolument rien à voir, je suis un grand partisan du typage.Pourquoi tes fonctions tu leur donne des paramètres typés et pas que des void*, après tout ils ont qu'a lire la doc pour savoir ce qu'il faut mettre.
Peut être une question de gout alors, j'évite autant que possible les instanceof en général.
Evidemment pour les checked exceptions il faut être raisonnable, mais j'aime mieux faire confiance a un compilateur qu'a une doc, d'autant qu'avec l'habitude on appelle régulièrement des fonctions, on va pas relire la doc a chaque fois et on est donc pas a l'abris d'un oubli
C'*EST* une question de goût.
C'est vrai qu'un instanceOf c'est rare dans mon code, j'essaie au maximum de travailler avec du générique ou du polymorphisme. Toutefois pour cette situation spécifique ça me serait utile. De toutes façons on a de bonnes chances que ce problème de catch de multiples exceptions soit de l'histoire ancienne d'ici la fin de l'année avec java 7.
Moi aussi j'aime qu'un paquet de choses soit vérifiées par le compilateur, cependant je considère que parfois c'est délicat de se retrouver au fin fond des couches inférieures d'un programme avec **une exception ingérable qui n'arrive jamais** dont on est forcé de s'occuper.
Remonter l'exception dans une RTE ne fait pas grand chose de plus que de la laisser se propager. Signaler avec des throws implique que les couches supérieures se débrouillent avec une exception sur les bras qui a tout perdu de son sens au fil des couches (couplage?).
En fait j'aurai juste voulu pouvoir annuler ce problème en utilisant une annotation de méthode, comme on le fait pour les warnings afin de signaler au compilateur "oui merci j'ai vu mais je choisis de ne rien faire dans ce cas précis".
Je dis pas que ça a que des inconvénients, parfois ça peut sauver la mise lorsqu'une méthode appelante doit soudainement faire face à une situation qui n'existait pas avant. Et je suis d'accord qu'on peut avoir la doc qu'on veut, les tests unitaires qu'on veut, on sera jamais à l'abri d'un oubli ou même tout connement d'un coup de téléphone inopportun qui nous sortirait de notre réflexion.
OK cette possibilité sur les exceptions ne sera donc pas donnée au développeur C++ comme au développeur JAVA dans un avenir proche. C'est à mon goût(et donc forcément pas débattable puisque chacun ses goûts) un manque au compilateur C++
[edit] il paraît qu'il y a une astuce pour "simuler" et faire crier le compilateur c++ si on veut programmer avec les exceptions.?.
" Dis ce que tu veux qui insulte mon honneur car mon silence sera la réponse au mesquin.
Je ne manque pas de réponse mais : il ne convient pas aux lions de répondre aux chiens ! " [Ash-Shafi'i ]
Pour avoir fait du C de base, C++ et Java durant mon BTS je me permet de donnée mon avis sur les dépassement mémoire^^
Il est en effet beaucoup plus simple en Java de détecter ce type d'erreur et d'en remonter à la source.
De plus il est vrai qu'un professionnel quelque soit le langage peut parer à ce genre d'erreur.
Cependant avoir moins de sécurité à gérer signifie un gain de temps. Et surtout évite une erreur d'étourderie. A condition évidemment que cette sécurité soit aussi fiable qu'on le désire
Au fait j'y pense, souviron34, tu nous avais pas promis en avril un exemple prouvant la supériorité absolu de Motif pour faire des interfaces graphiques (ou au moins un exemple qui ait pas un look années 80)
si j'eu le temps, j'eu fait
Et entre parenthèses, ce n'était pas pour prouver quoi que ce soit de supériorité absolue, juste pour dire que ce qu'on fait avec de nouveaux outils, on peut le faire avec des anciens , et qu'en particulier Motif est pas plus mal que wx, gtk, qt, et autres...
Peut-être qu'un jour j'aurais le temps
"Un homme sage ne croit que la moitié de ce qu’il lit. Plus sage encore, il sait laquelle".
Consultant indépendant.
Architecture systèmes complexes. Programmation grosses applications critiques. Ergonomie.
C, Fortran, XWindow/Motif, Java
Je ne réponds pas aux MP techniques
Vous avez un bloqueur de publicités installé.
Le Club Developpez.com n'affiche que des publicités IT, discrètes et non intrusives.
Afin que nous puissions continuer à vous fournir gratuitement du contenu de qualité, merci de nous soutenir en désactivant votre bloqueur de publicités sur Developpez.com.
Répondre avec citation
Partager