Reprise du message précédent :

 
nan ca (desole) c'est naze comme explication   surtout en java ou y'a pas d'autoboxing. A la rigueur un Integer
 
d'ailleurs y'a pas d'exception en C
 

 
ce genre de reponses cretines me saoulent
ok java c'est le meilleur langage, le reste c de la merde bugogene, on l'a compris. merci

je parlais de ceux qui ont fait le C++ ...
 
Sérieusement, c'est plutot une bonne idée d'avoir un ancêtre commun aux exceptions : déjà c'est logique par nature : uneException, bha c'est une exceptino quoi, c'est pas un entier, pas un objet quelquonque, c'est un truc qui peut être lancé ... Ensuite, ca permet de factoriser les propriétés communes (stacktrace et totu le toutime).

   
 
Ca s'appelle de l'humour ce que tu as quoté, là ...

tout à fait, je suis d'accord avec ton point de vue que tu as donné plus haut

et puis ça permet à ceux à qui ça donne des boutons de declarer les throws de leurs methodes de mettre throws Exception

plus sérieusement, je suis pas le mieux placé pour te répondre puisque je trouve que les checked c'est une bonne idée
 
Mais j'imagine que y a pas de bonne ou de mauvaise solution. C'est une question de point de vue et de priorité.
 
D'un côté le checked est contraignant mais apporte de la robustesse si il est bien employé (mais aussi des bug difficilement visible dans le cas contraire), de l'autre côté le unchecked est moins pénible pour le développeur pressé mais demande des efforts beaucoup plus considérables pour le développeur consciencieux pour obtenir le même niveau de robustesse.
 
Après c'est une question de choix lors de la conception du langage ...

moi je trouve ça super contre-productif : les débutants mettent des catch vides (alors que sinon ils auraient eu le bon comportement).  
Et de toutes façon les docs sont trop vagues pour faire quelquechose avec une exception vérifiée qu'on a reçu (tous ceux qui catchent des IOException savent de quoi je parle : c'est tellement vague qu'a part la faire remonter et afficher à l'utilisateur le message qui est dedans, on peut rien faire).
 
Les checked exceptions, c'est typiquement la fausse bonne-idée.

De toutes façons on est obligé d'aller dans le code des applis, les effets de bords sont pas documentés (notement prises de références ou copies) et on a quasiment aucune indication sur les performances et la complexité des bordels mis en jeu (on sait rarement si une fonction est faite pour bourriner dessus ou si on doit faire nos caches nous-même, ou si sa petite soeur est, elle, fait pour bourriner dessus).
 
Dans l'absolu, il est plus simple pour l'IDE d'aller voir lui-même ce qu'il se passe au niveau des exceptions (ça lui permettra au passage de nous parler des fonctions qui acceptent null en entrée ou non) et de faire documenter par le dev les effets de bords et la complexité que l'inverse.

bha non, le bon comportement c'est de traiter els exceptions quand on le peut, pas de laisser planter le programme ...
 

Une exception ne peut pas toujours être précise (c'est dû à la notion de signature des interfaces). Mais dans tous les cas elle permet de savoir qu'un truc a planté. Savoir quoi c'est presque du luxe
 
Et puis dans le cas des IOException, la plupart du temps tu peux savorien fonction de la nature de l'objet que tu intéroge quel type d'exception tu peux obtenir (en allant voir dans la doc) : FileNotFoundException à l'ouverture d'un fichier, UnknownHostException en cas de lecture sur le réseau, etc ...
 
Mais je suis d'accord : la notion d'interface oblige à déclarer des exceptions "génériques" qui masque la nature réélle de l'exception ... Mais dans ce cas là, on en est à l'état de la unckeckedExceptino : on doit allé voir dans la doc pour voir quelle exception cachée la IOException  
 

ben vraiment je trouve pas
 
Avec un poil de rigueur c'est hyper puissant !

la question que je me pose benou, c'est de savoir si tu ecrirais un code different (moins blindé) si tes exceptions etaient non checkés

ben non, et heureusement que c'est pas le cas !
Si je devais aller voir le code de toutes les librairies que j'utilise

Ha mon avis oui. Pour avoir le même blindage ca demanderait un effort beaucoup plus important : avoir la doc à disposition pour pouvoir regarder à chaque appel d'une API ce que ca peut balancer.
J'imagine même quand tu dois débugguer un code qui n'est pas toi ! C'est doit être vraiment horrible !
 
Et puis c'est surtout que tu risques de passer accidentallement à côté d'exception ...
 
Avec des checked, tu sais que si tu traites correctement les catch tu peux garantir que ton programme fonctionnera correctement. Avec des unchecked, c'est risquer de prendre ce genre de pari : comment être sûr que tu n'en a pas oublié une quelque part ?

Tout ça pour un sleep()....

 
j'aurais jamais cru que mon pétage de boule prendrait à ce point !  

 
bah j'avais deja essayé d'amener ca sur blabla ca m'avait valu un "" alors bon

 
non, l'exception remonte jusqu'au main, t'as la stack trace tu vois en deux coup de cuiller a pot d'ou ca vient (cf quand tu te manges un nullpointer ou dans le genre, tu passes pas des heures a t'arracher les cheveux sur le "ou ca vient ?" )

euh tu crois vraiment que ton end user il a envie de voir une stacktrace sortir de ton appli?
 
 
meme des soit-disant developpeurs java sont pas capables de decrypter correctement une stacktrace alors jte dis pas les end users..

nan mais ca ok, moi je te parle de quand tu dois relire du code : comment savoir si le mec laisse passer une exception parce qu'il la traite plus haut ou si il a oublié de la gérer ou si elle ne se produit pas dans ce cas là ...
 
T'es toujours obligé d'avoir une vision précise de tout le projet => quand tu débarque dans du code qui est pas à toi ca doit être horrible.
 
quand au fait de disposer du stacktrace, comme ca a déjà été dit plein de fois, y qu'à correctement gérer le catch. Le minimum étant un bon vieux e.printStackTrace();

 
on parlait de debugguer

toi tu es de ceux qui ont pas aimé la possibilité d'afficher l'état des registres quand une appli plantait sous win 9x

barf, avoir la possibilité, pq pas, avoir un écran bleu, non merci.
(laisser remonter une ex jusqu'au main en java, c'est l'equivalent d'un core dump ou d'un ecran bleu pour moi...)

je prefere le core dump (a l'ecran bleu)

un core dump de l'os, c'est mal

 
oué ben vu que je code pas en kernel space j'ai normalement pas a craindre ce genre de blague

 

 
fallait que tu la sortes celle là
 
(pour ceux qui sont intéressés par la private joke, deux de nos 'collègues' ont passé la journée devant 2 problèmes 'hyper grave'. Greg est arrivé a lu les 2 stacktraces et en 15 min montre en main c'était reglé)
 
j'avais bien rigolé ce jour là (surtout comme les deux idiots ont nié l'affaire )

sinon pour le débat, je suis tout à fait d'accord avec benou et --