Bonjour,  
 
J'ai un ch'tit problème avec les exceptions. Je m'explique :
J'ai un formulaire qui demande à l'utilisateur de rentrer entre autre une date.
Je voudrais déclencher une exceptions lorsque la date entrée n'est pas correcte. Par exemple, date="exemple1";
 
J'ai écris le code suivant :  

 
Ainsi, j'aimerai afficher un message d'erreur en console.  
Par la suite, je créerai une classe exceptionDateErreur() qui gérera les erreurs de date en affichant un tel message d'erreur.
Jusque là pas de problèmes, les excpetions sont biens captées par mon bloc try.
 
Mais moi, ce que j'aimerai, c'est que la corps de la fonction s'arrête là. C'est-à-dire, dès que l'excpetion est déclenché, rien n'est éxécuté par la suite.
 
Y a t-il un mot clé à ajouter pour faire cela?
 
 
Merci d'avance.

C'est à toi à agencer correctement ton code pour que "plus rien" ne s'exécute après l'exception, ctout.
 
Dès que le programme rencontre une exception, il cherche le bloc catch correspondant et l'exécute, puis de même avec le bloc finally. En l'absence de bloc catch, l'exception remonte le stack et c'est le même petit jeu au niveau de l'appelant.
 
Pour lancer une exception, tu fais un throw.
 

un bon petit System.exit ?

Ca va pas aller, car System.exit(0) va quitter l'application.
Or moi, je souhaiterai seulement "sortir de la procédure"...

ben return alors ...

Return  ok dans le cas d'une fonction, mais ici c'est une procédure.  
Je crois que je vais devoir utiliser une variable(t), qui sera mis à vrai lorsqu'elle passe dans le catch.
Ensuite il suffira de tester cette variable :  
si t=true -->on éxécute pas la boucle
sinon on l'éxécute
 
C'est pas très propre mais ça rêgle le pb.

y a pas de procédure en java. c'est totu des fonctions. et tu peux utiliser return seul.

J'ai l'impression que tu t'embarques dans une mauvaise direction. Il est très rare que ce genre de contorsion trouve sa place dans un code correctement conçu.
 
Tu peux toujours filer ta solution si tu veux un avis critique et constructif.

Le mieux à faire c'est de faire un throw dans ton block catch afin que l'appelant soit au courrant que le traitement ne s'est pas bien passé.
 
PS : En langage objet on n'a ni fonctions ni procédure mais des méthodes

Alors je vais vous expliquer mon problème, ça va être aussi simple. Le but est de choper des valeurs d'un formulaire de différents type.
Voici le code associé

 
 
Donc moi ce que je souhaiterai, c'est déclencher des exceptions quand :
  - le format de la date est erroné, en sachant que la date peut etre vide
  - le format de la durée est erroné
 
Voilà le pb ...
 

ben les exceptions sont levées pour toi, mais là tu les catches sans rien faire ... fait le traitement approprié dans les catch.
 
et les chaines de caractère, ca se compare en faisant .equals(), pas == ou !=

Tu ne gère manifestement pas les exceptions correctement.
 

C'est ce que j'appelle "catch-and-burry" : tu attrapes l'exception et tu l'enterres. Ce n'est jamais une bonne idée.
 
1. Soit tu traites l'exception sur place:

 
2. Soit tu la relances, éventuellement après avoir loggé:

 
3. Soit tu ne l'attrapes pas. Le bloc finally éventuel est exécuté et l'exception remonte le stack, à charge pour l'appelant de la traiter ou de la déférer.
 
4. Cas rare : l'exception est "normale", il n'y a rien à faire. Dans ce cas, il est bon de mettre un commentaire indiquant cette condition :

!!!
Le pire, c'est que ça marche sans doute dans ton cas, mais c'est jouer sur un effet de bord dangereux.

Tiens Sircam, tu pourrais expliquer un peu ton cas 2 stp ?
Ce que ça fait exactement et l'intérêt de le faire (le throw dans le catch) ?
 
Merci

ben "tu la relances, éventuellement après avoir loggé", je vois pas ce qu'il y aurait de plus à dire?

sircam>>pour le cas 4, prière de mettre un exemple ou l'on catche une exception spécifique

 
Scuse je débute en Java    
 
Tu relances l'exception ? Tu relances l'appli ?
 
le "la" me laisse dubitatif

ha, oui, tu relances l'exception. elle continue à remonter la pile de la meme façon que si tu ne l'avais pas catchée quoi...

Cas 2° : non, y'a rien de plus à dire, ça dit ce que ça fait et ça fait ce que ça dit.
 
Cas 4° : de fait, c'est plutôt une exception bien particulière plutôt que Exception qu'on va attraper. NumberFormatException, InterruptedException p.e.
 
joquetino, je crois que tu vas un peu trop vite. Je te conseille de laisser ton problème concret de côté et de faire des tests de bases avec les différents cas exposés.
 
Revois le chapitre consacré aux exceptions avant de continuer. A défaut, tu vas prendre de très mauvaises habitudes et ça va pas être joli à voir.

C'était po mon problème, me suis incrusté dans la conversation
 
Mais je vais relire qd mm, le cas 2 me parle toujours pas

Ooops... M'en fout, ça vaut pour toi aussi
 

M'enfin, c'est pourtant simple.
 
Plutôt que de simplement laisser remonter l'exception (car tu ne sais rien en faire), tu veux d'abord la logger. Légitime, non ? Tu fais cela dans un bloc catch. Mais comme tu ne sais toujours pas quoi en faire - tu n'as fait le catch que pour la logger, pas pour la résoudre -, tu la rebalances, hop la patate chaude, j'ai pris note de ce qui c'est passé dans mon catch mais je sais rien en faire, throw e.

Mais pourquoi la relancer, si on ne sait rien en faire, on la log et basta (i.e. le même code sans le throw). Quelle est la différence alors ?
 
Tapez pas trop fort
 
EDIT : merci pour les explications, je sens que j'aurai pas perdu ma journée si je comprends ça

la différence c'est qu'un autre bout de code, qui sait comment traiter le probleme, peut le faire.

Bon, je ne vais frapper. Du moins, pas encore.
 
"On la log et basta". Et quoi, tu continues l'exécution de ton programme comme si de rien n'était ? Alors que tout le reste du bloc try après l'instruction qui soulève l'exception n'est même pas exécuté ? Ton programme se comportera de manière tout à fait inconsistante, puisqu'une partie du flux normal n'aura pas été exécutée, mais qu'il n'y aura aucune erreur signalée ni aucune correction apportée.
 
DONC, tu la logges, et tu la relances. Si l'appelant ne sait rien en faire, il fait de même. En bout de chaîne, un composant devra bien en faire qq chose, ne serait-ce que "Erreur technique, blablabla" à l'écran. A défaut, la JVM termine (ça ne doit arriver que lors du debugging, hein, sinon, heu, c'est pas super user-friendly. Ou alors, c'est un application type interne pour des power user).

Aaaah ben oui...  
Donc les appels à la méthode qui contenait ce try/catch devront être eux-même dans un try/catch pour éventuellement récupérer cette exception, alors qu'en ne mettant pas le throw, ce n'est pas la peine (mais on perd alors l'exception).
 
Dis moi si je me plante, mais en tout cas merci
 
PS : le forum agonise là ?

Ok merci Sircam, ça confirme ce que je pensais
 
C'était pas la peine de frapper finalement, la méthode douce a encore de beaux jours devant elle

tout ça pour dire que si c'est pour catcher une exception et ne rien faire, autant pas la catcher du tout.

   
Non, l'appelant ne doit pas forcément encadrer l'appel dans un bloc try/catch. Il peut se contenter de déclarer qu'il peut lui-même, par l'intermédiaire de l'appelé en l'occurence, générer une exception à l'aide de la clause throws.
 
Si l'exception est unchecked, ce n'est même pas nécessaire (et c'est le cas implicitement dans tout programme : tu fais rarement un catch de OutOfMemoryException, or cette condition peut se produire n'importe où, en dehors de tout bloc try/catch ou de clause throws).
 
Et en ne mettant pas le throw, on ne perd pas l'exception si on n'est pas dans le bloc catch, ou s'il n'y a pas de bloc catch, nous sommes bien d'accord (cas n°3 supra).

Euh vi j'avais oublié la possibilité du throws.
 
merci pour toutes ces explications
 
(C'était bien une réflexion de fonctionnaire ça, R3g )

sircam > mauvais exemple ; OutOfMemory est une Error, qui par définition n'est pas sensée être catchée, sauf à de très rares exceptions.

Si, bon exemple, justement : elle est unchecked, donc la clause throws n'est pas nécessaire et, comme je le dis, tu en fais rarement un catch.

Ce que je voulais dire c'est que c'est une Error, pas une Exception. Les Error et les RuntimeException ne représentent pas du tout le même gere de choses.

En fait, on devrait plutôt parler de Throwable pour être tout à fait général en théorie, mais comme effectivement la sous-classe Error est généralement tout à fait ignorée, on ne s'interesse en pratique qu'à Exception.
 
Tu as raison et pour le surplus, ça nous évite d'embrouiller les esprits. Il faut préciser que les exceptions unchecked sont du sous-type RuntimeException :-S
 
Mais il ne serait pas incorrect de dire que IllegalArgumentException est une exception unchecked.
 

ah oui tiens...vous faites vos exceptions perso comment : vous les faites hériter d'exception, vous implémentez Throwable ? vous sous classez une exception existante ?

ben ça dépend

de quoi justement

bah de ce que ton exception represente pardi
 
le seul truc qui ne varie pas, pour moi (enfin, j'essaie de m'y tenir), c'est les constructeurs: je n'expose que ceux dont j'ai réellement besoin, jamais plus les 4 constructeurs d'Exception.

Tu peux imaginer une sous-classe d'Exception qui sera la classe mère de toutes les exceptions de ton application. Ce qui me paraît de bonne pratique.
 
Typiquement, ton exception a au moins un message d'erreur (pour faciliter le logging). Tu peux mettre en place un système de codes.
 
Et selon les besoins, toutes les infos utiles et pertinentes  en fonction du contexte.

où il serait d'ailleurs de fort bon aloy d'utiliser une enum

bof, perso je préfere ne pas avoir d'exception applicatives, et hériter de celles qui sont correctes si possibles.
 
par exemple, si j'ai une erreur de connexion, ca me semble logique de surclasser IOException

Merci, je bosse en 1.3, alors