Reprise du message précédent :

Merci, je bosse en 1.3, alors    

ben dans certains cas tu as pas de quoi hériter /ou/ tu dois cacher le systeme sous-jacent.
(exemple, tu construis un bidule qui peut aller se connecter de maniere transparente sur du ldap, une db ou un file system pour par exemple logger un user dans ton appli.. tu peux pas te permettre d'avoir une interface qui expose les exceptions de tous les systemes sous-jacents possibles)

+1
 
Préfère une exception custom type business (... waow... le charabia) qui permet de stocker l'exception à l'origine, IOException, si tu ne veux pas perdre l'info tout en masquant ces détails dont les couches supérieures n'ont rien à foutre.

bon allez, j'ai hésité un peu, mais jla fait:

ou

ben oui evidemment, ca depends des cas

Explique ?!

dans cette classe de pb, ça dépend pas, c'est catch pour tout le monde.
 
 
sircam > y'a un race condition entre le file.exist() et l'utilisation suivante du file. Et comme java ça rame, y'a un risque majeur /o\ En plus l'autre est plus rapide. et puis en fait y'a pas de race, parce que dans tous les cas, si y'a un pb, l'exception sera levée, donc pas la peine de vérifier avant.

putain si
je vérifie avant, et apres je ne catche ou remonte que les IOException.
 
bordel

Beh, surtout d'un point de vue design, je préfère séparer le traitement normal de la condition d'exception...

mais là c'est pas de ta faute c'est pas toi qu l'a faite l'interface !
 
En plus en séparant, tu introduits un point de fragilité artificiel : dans "mon" truc, si tu as un pb, l'erreur est claire, tu la remontes à l'utilisateur. Dans le tiens, si tu as un race, tu as une erreur innatendue avec un statut douteux (puisque la "vraie" est sur le exist()) à remonter à l'utilisateur.

je répondais à ca :
 

Nicolas, tu répondais à qui ?
 

Par "séparer le traitement normal de la condition d'exception", je parle bien d'un bloc try/catch (formulation gratuitement pompeuse).

sircam > à toi, mais j'avais mal compris ce que tu disais

j'ai pas encore bien le réflexe de généraliser l'utilisation d'exceptions...pour le moment, je m'en sers surtout pour l'effet propagateur que ca a, en particulier pour faire remonter les exceptions vers la GUI...
 
j'avoue que pour le file.exists(), j'aurais choisi ca au lieu de l'exception, et du coup, je me serais pris le pb expliqué par nraynaud

Bonjour à tous,  
 
J'ai un ch'tit souci toujours avec les exceptions.
J'ai tjrs un formulaire où je chope des valeurs.
Voici ce que je fais avec ce formulaire :  

J'ai éxécuté ce bout de code chez moi. Pas de souci, il s'éxécute bien. Par contre,  
chez un copain, j'ai le droit au message :  
Java.lang.NullPointerException
 
Auriez-vous une idée du problème dans le code ci dessus?
Quel procédure appelée pourrait déclencher cette exception?

apprend à lire les stacktraces, tu verras ça aide.

--, calme toi
 
regarde la ligne indiquée dans la stacktrace. regarde ton code à cette ligne, tu peux parier que l'objet que tu y utilises n'a pas été instancié (y pas eu de new, quoi)

Pourtant si un objet n'a pas été instancié ce code ne marcherait pas chez moi.....
Or celui ci fonctionne chez moi et pas sur la machine d'un copain...

Le stack trace (la partie utile en tout cas) serait peut-être le bienvenu ?

ca peut venir de tout un tas de raison : fichier manquant => getRessourceAsStream qui retourne null, ou autre

Qu'appelez vous la stack trace?  

ha, d'accord.
je laisse la main.

Le message d'erreur que la machine virtuelle met gratuitement à ta disposition, et dans lequel tu as lu NullPointerException.

le truc plein de lignes que t'as du vori affiché dans la console quand le programme a planté.
stack = pile d'appel
trace = affichage (en gros)
 
ca t'affiche la pile d'appel au moment de la génération de l'exception => tu peux retrouver où le prog a planté.
 
t'es sur que tu connais java ?

dis benou, calme-toi
 
 
 
 

 
 
(et sinon, je pense pas qu'il ait vu la stacktrace vu qu'il catch les exceptions et les avale gentiment en balançait un MessageDialog qui ne montre que le getMessage )

biensûr que je connais java, seulement je n'ai jamais entendu parler de stack trace.... Passons.
Pour revenir au problème, ayant un bloc try/catch, le programme ne plante pas mais m'affiche le message queje lui ai demandé d'afficher en cas d'erreur.
Je l'ai enlevé pour voir où ça plantait, et là j'ai l'erreur suivante :
java.lang.Error: Unresolved compilation problems:  
 Unhandled exception type ParseException
 Unhandled exception type ParseException
 
Normal je ne capte pas les erreurs liées à l'appel de la procédure dateStandard.parse(dateFin);
 
Donc quel exception, moins générale que Exception dois déclencher ici?
 

Y'a p'tete une chtite console qui vomit gentiment les erreurs en cachette, à l'abi du GUI tout propre. Ou même un log.
 
Sinon, joquetino, il est évident que tu programmes de manière profane sans comprendre ce que tu fais. Et ça, c'est jamais bon signe.  

Sircam, certes je débute en java (j'y suis seulement depuis moins d'un mois), maintenant supposer que je programme sans comprendre, ça n'engage que toi.    

plutot que de virer le try/catch (ce qui rend ton code non compilable), affiche la stacktrace en faisant e.printStackTrace(); dans le catch
 
remarque : c'est très rarement une bonne idée de cacther Exception, et ca l'est encore moins de ne pas afficher la trace de cette exception dont tu ne sais rien.
 
 
et désolé si tu as mal pris ma remarque ... c'est juste que c'est quand même très très couramment utilisé le terme stacktrace en java ...

J'ai fais ce que tu m'as conseillé et j'ai réussi à trouver la procédure qui plantait. Merci.  
Par contre, pourquoi dis-tu que c'est rarement une bonne idée de catcher Exception?

parce que tu ne sais pas ce que tu catches et que donc, tu ne sais pas quoi en faire.
 
à quoi ca sert de catcher une exception si tu ne sais pas quoi faire pour résoudre le problême qui en est la cause ?

Oui en effet. Mais dans mon cas, je sais l'erreur que je catches.
 
Merci encore de votre aide. @ la prochaine.

parce que toute exception hérite d'exception
 
c le catch le moins précis que tu peux faire, et par conséquent ca t'aide pas à trouver la source du pb...
 
sinon pas catcher une parseError sur un formulaire, t joueur...y'a une chance sur une que le user fasse une faute la première fois...pis si t dans le cadre d'une GUI, tu fais un joli popup qui prévient que ct pas le bon format...

si tu sais l'erreur que tu catches, catche cette exception là alors, pas Exception

là dans ton cas ca ressemble plus à un "je cacth Exception pour que le compilo arrête de gueuler"

 
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.