Bonjour a tous,
g du mal a comprendre l'interet des exception(si on veut les faire nous meme).
Si je prends l'exemple d'une classe date dans laquelle il y a la methode affecter(pour une date)
et que si on veut que le mois soit ccompris entre 1 et 12,on fait ceci:
 
...
public void affecter(int j, int m, int a)
{
 
 if (m >= 1 && m <= 12) this.mois = m;
 else
 {
 
  System.out.println("date non conforme" );
  ..
 }
}
 
 
 
 
alors qu'avec les exceptions il faut faire  
une classe correspondant a l'exception comme ceci:
 
public class DateNonConforme extends Exception {
    public DateNonConforme(String e)  
    {
        super("Date non Conforme:" + e);
        ...
    }
}
 
+rajouter dans la classe date ,pour la methode affecter cela:  
 
 
public void affecter(int j, int m, int a) throws DateNonConforme  
{
    ...
    if (m >= 1 && m <= 12) this.mois = m;
    else throw new DateNonConforme(" mois " + m);
    ...
}
 
 
 
et en plus dans le main (ou bien ou l'on veut) faire un try catch pour lever cette exception
 
Voila je ne comprends pas pk utiliser des exceptions alors qu'un simple if suffit
je vous remercie d'avance pour votre aide.

J'ai un peu la flemme de faire une réponse détaillée, je vais surtout te filer des sitations :
 
James Gosling (créateur de java) :
http://www.artima.com/intv/solid.html
 
Bertrand Meyer (big boss de la qualité, créateur de Eiffel, et surtout de la conception par contrat) :

(son livre "conception et programmation orientées objet" propose 25 pages sur les exceptions, soit probablement plus qu'un bon paquet de livres)
 
ceci élimine ton premier exemple, car une fois affiché à l'utilisateur, on peut rien récupérer de l'erreur, dans le programme, on ne sait même pas qu'elle a eu lieu.
 
 
D'autre part, les exceptions offrent un système hiérarchique de traitement d'erreur, à 2 niveau.
 
Première chose, lorsqu'on a :

 
j'ai la possibilité de traiter l'erreur à l'appel de f2, à l'appel de f1 ou encore plus haut, je peux donc rapporter l'erreur au niveau de détail que je veux (et même faciliter l'enquête avec la "cause" de l'erreur) je traite donc au niveau sémantique que je veux. Par exemple, lors d'un accès à la base de données, je vais recevoir une exception "impossible d'allonger le segment de rollback, yapu de mémoire, c'est la dèche" mais je vais mon contenter de dire à l'utilisateur "la base est en vrac, laisse béton tout ce qui concerne la base, appelle le DBA", mais je peux décider de stocker la transaction dans un fichier, en attendant le retour de la base. je peux donc "catcher" l'exception au niveau que je veux dans la pile d'appel.
 
 
Il y a un autre aspect : la hiérarchie des erreur est visible par la hiérarchie des sous-classes de Throwable, qui permet par exemple de dire "il y a eu une erreur d'entrée-sortie" (IOException) ou plus finement "le ficher que vous avez tenté d'ouvrir n'existe pas" (FileNotFoundException) on voit que cette hiérarchie est assez lié à la première, en faisant une action concrète comme tenter d'ouvrir un fichier, on aura une erreur concrère (FileNotFoundException) et en faisant un truc vague "sauver la conf" on aura une erreur plus vague (IOException : "yapu de place", "on a pas les droits", "la connection avec la machien de sauvegarde est perdue" ? on sait pas, on est pas à ce niveau de détail).
On a donc une hiérarchie des erreur mappée sur la hiérarchie des types statiques, une habitude qu'on prend dans les langages statiquement typés : mapper à peu près tout et n'importe quoi sur les types (et des trucs chelous, j'en ai vu !), pour des raisons de sécurité.

Les exceptions sont de 2 types : les "run-time exceptions" et les "checked exception" :
Les "run-time exception" sont des exceptions correspondant génréralement à des "erreurs" de programmation genre NullPointerException, IndexOutOfBoundException etc... et de ce fait elles ne doivent généralement pas être récupérées par le systeme du try/catch.  
Les "checked exceptions" sont généralement des exceptions innatendues et reflètent un comportement "anormal", par exemple perte de la connection avec la base de donnée (SQLException)
 
Ton exemple rentre plutot dans le premier cas et tant qu'a faire je réutiliserais au maximum les exception java existantes dans la mesure du possible :
 

 
Si maintenant tu est confronté directement a l'utilisateur, tu n'a effectivement pas besoin d'exception et tu dois faire les tests de validité avant d'appeler la methode (car l'utilisateur peut saisir ce qu'il veut); c'est ce quon appelle un pré-condition dans la programmation par contrat.

non, elles sont justement attendues (puisqu'elles sont déclarées), ce sont les exceptions du domaine.
 
Si on parle de base de données, on parle de connection et on sait qu'on risque de la perdre. Si on parle de fichier, on sait que ça peut merder à l'écriture.
 
Par contre un NullPointerException, ça n'a rien de spécifique à une écriture dans un fichier, c'est transversal, c'est dû au système de types de java, pareil pour un IllegalArgumentException.
 
Je dégagerais une 3ème catégorie qui est celle des exceptions asynchrones : tout ce qui n'est pas directement de notre faute, un signal unix, un OutOfMemory (qui peut survenir sur un simple appel de méthode) et quelques erreurs qu'on peut attribuer à la fatalité.

 
tout a fait d'accord avec toi cette catégorie existe effectivement ce sont les classes héritant de 'Error', mais "en général" on n'a  ni a en créer ni à les utiliser

 
Le fait de perdre la connection est 'anormal' mais possible. Le mot 'innatendu' n'est pas adéquat comme tu l'a signalé  

 
oui, mais pour moi, ca ne veut pas dire grand chose. Ce sont uniquement des exceptions resultant d'une erreur de coding.
NumberFormatException est bien "spécifique" à un type de formatage chaine de caractere/numérique, mais c'est pas pour autant qu'elle doit être interceptée ou propagée ; elle indique que le programmeur s'est planté dans son code en essayant de convertir une chaine de caractere en valeur numérique.  

pas que.
elle peut aussi indiquer que l'utilisateur n'a pas entré un bon format, et ca peut etre utile de le propager pour afficher une belle boite de dialogue

 
ben en fait je fais pas comme ca personnellement. Pourquoi ca ? parce qu'en fait les runtimes ne sont pas destinées a être "catchées". Le fait qu'un utilisateur entre une valeur non numérique ou trop grande ou trop petite est un comportement normal à mon avis et ne doit pas faire l'objet d'un traitement "exceptionnel".
Joshua Bloch a dédié un chapitre au traitement des exceptions dans son excellentissime livre qui explique bien ça:
http://java.sun.com/docs/books/effective/

bah effectivement, en dehors des runtime (qui resulte si je me trompe pas d'erreur de programmation) je catche tout, c'est pas si dur et un NumberFormatException arrive facilement, et je veux pas que ca crash l'appli

j'ai pas bien compris. Tu "catches" NumberFormatException ?(c'est une runtime)  
Sinon + 1.
Je suis d'accord avec toi mais je pense que les 'Error' ne doivent pas être catchées non plus (sauf dans des applications critiques nécésissant par exple le redemarrage de la jvm).

je voulais dire que je vois en fonction de l'exception, des trucs comme NullPointerException ou IndexOutOfBoundException, je les catch pas parce que c'est des erreurs de prog ou alors quelque chose que je veux pas analyser, mettre toutes les runtime dans le meme paquets, c'est peut etre bien en theorie mais en pratique je vois pas toujours l'interet

 
ok je vois ton point de vue, mais je n'y adhère pas cependant  

ok,Donc d'apres ce que g compris dans vos reponses,les 2 types d'exception run-time exceptions et les checked exception doivent etre levées pour que le programme puissent continuer sans erreurs.
 
Cependant lorsqu'il s'agit d'erreur d'utilisateur ,genre le gars ecrit une date érronée,on effectue des jeux de test sur cette date pour savoir si elle bonne avant de la construire.
 
Merci pour toutes vos reponses apportées

 
Non, les runtimes ne doivent pas être levées.  
Pour le reste c'est ca

ok,merci