Reprise du message précédent :

 
Ne le prends pas mal, joquetino.
 
Comme le dit benou, le terme stack trace fait partie des bases en java, et tes questions montrent clairement que tu ne comprends pas ce que tu es en train de faire.
 

suivi de

Tes questions supra, la soupe procédure/fonctions/méthodes, ton premier post me permettent d'affirmer que tu ne comprends pas ce que tu fais.
 
Ce n'est ni gratuit, ni méchant.
 
Il n'y a pas de mal à ne pas savoir, mais manifestement, tu t'attaques à une matière trop épaisse par rapport à tes connaissances.
 
Il vaut mieux commencer par des choses plus simples, le temps de comprendre et de maitriser les concepts.

moi aussi j'ai commencé en gérant les exceptions n'importe comment. Malheureusement, c'est pas enseigné à la fac
 
avec le temps et l'expérience on apprend ...  à défaut de savoir comment gérer l'exception, il ne faut pas perdre d'information => printStackTrace.

Malheureusement, une fois sur deux seulement. Pas mal de développeurs gardent leurs mauvaises habitudes, se contortionnent pour que ça marche, mais en passant bien à côté de la bonne méthode.
 
Les "catch and burry" et autres horreurs ne sont pas que l'oeuvre de développeurs inexpérimentés.    
 
Ca vaut pour la gestion des exceptions et pour un tas d'autres trucs.
 
Je ne sais pas ce qui fait que la sauce prend pour certains mais pas pour d'autres. Capacité de remise en question et d'acceptation des critiques ?
 
Et c'est pour ça qu'il convient d'attirer l'attention de ton interlocuteur égaré.

Mouais enfin on est bien aidé quand même. Si beaucoup font des catch Exception pour pas avoir d'emmerde, tous les ide signalent quelle est (sont) la (les) exceptions(s) à catcher.
Donc pour prendre de mauvaises habitudes là dessus faut vraiment en vouloir

 
Je suis à la fac et nous avons appris à programmer en Java en deux heures de cours et deux tps. C'est donc assez difficile de bien maitriser ce langage. On nous demande, avec ce peu de connaissances, à programmer un petit logiciel.
Mais bon, c'est en faisant des erreurs qu'on apprends, non?

concernant la présentation à l'utilisateur, j'ai tenté ça :

vous pensez quoi de l'idée (en fait, c'est la chaine de causes) ?
 
déjà c'est pas localisable

 
bien sur (je suis aussi à la fac, et g aussi une prof qui fait pas forcément gaffe)....
 
mais qd les gens attirent ton attention, rejette pas le truc...
 
la sémantique des exception c très pratique..surtout que tu peux chainer les catchs...
 
certaines de mes méthodes renvoient 3 exceptions différentes ...que je remonte à la GUI et qui via le getMessage() me permettent de prévenir proprement qu'une couille a eu lieu...et de manière différentes (pour certaines exceptions je met un popup Error, pour d'autre je demande une confirmation...
 
si tu catch que Exception, tu perds cette faculté de tri

Ah mon avis ça dépend de ton utilisateur type : le genre de choses que tu présentes suppose que l'utilisateur sait ce que cest qu'une exception, comprend l'enchainement des causes qui est présenté et sait déduire la cause du problème du message et de la nature des exceptions. Bref à mon avis c'est un soft pour poweruser qui présente les erreurs comme ça.

+1.
 
Pour être user-friendly, tu devrais re-mapper chacune des exceptions usuelles vers une traduction pour lambda user. Avec par défaut le très irritant "An error occured".
 
Mais je ne me priverais pas de l'info fournie par le stacktrace. P.e., tu peux prévoir un bouton "more" qui agrandit la boîte de dialogue et fournit le stack trace, avec un bouton copy.

Comme les messages d'erreur de windows 95  

A la différence que sous Windows, ni le message de base, ni le "more" ne t'étaient d'aucune utilité    

sauf que ça on peut pas le faire.

les execptions (IO surtout) ne sont pas assez précises par leur type, et remontent le message d'erreur de la chaine d'erreur de la fonction C d'en-dessous en général, ce qui rend les choses extrèmement bancales.
 
par contre, mon exemple n'illustre pas trop ce phénomène vu que c'est réellement le gethostbyname()  qui a échoué donc c'est une exception qui ne mappe pas une erreur C.

Bien sûr, mais avec java.net.UnknownHostException, tu ne risques pas de te gourer des masses... BindException, ConnectException, SocketTimeoutException, autant d'exception fort sympathiques à mapper.
 
Pour le reste, c'est vrai que tu peux pas faire grand chose, d'où repli stratégique sur des messages plus généraux et le stack trace en bonus.