Discussion :

[austin57]

Bonjour à tous,

Comme beaucoup ici, je débute en Java. Je suis en train de regarder le système de fonctionnement des levées d'exception.
J'ai compris dans les grandes lignes le fonctionnement. Mais certains détails m'échappent. Par exemple sur cet extrait de code:

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
	public void setAge(int age) {
		try {
			if (age < 15) {
                              MON CODE
			}
		} catch (Exception e) {
			throw new IllegalArgumentException("Interdit au moins de 15 ans.");
		}
 
		this.age = age;
	}
 
	public void setAge(String age) throws ParseException {
		try {
			setAge(Integer.parseInt(age));
		} catch (NumberFormatException e) {
			throw new ParseException("Doit être un nombre", 42);
		}
 
	}

Dans le cas de la première méthode, je lève l'exception IllegalArgumentException mais Eclipse ne m'oblige pas à spécifier cette levée d'exception dans la signature (pas besoin de throws IllegalArgumentException).
A l'inverse, dans la méthode surchargée de setAge, Eclipse m'oblige à ajouter "throws ParseException".
Pourquoi cette différence de traitement sur des méthodes quasi identique?
Le fait que IllegalArgumentException soit une erreur héritant de RuntimeException et ParseException de Exception a-t-il un lien?

Merci d'avance pour vos éclaircissement.
Damien

[joel.drigo]

Salut,

Le fait que IllegalArgumentException soit une erreur héritant de RuntimeException et ParseException de Exception a-t-il un lien?

Oui, une RuntimeException (dite unchecked exception) ne nécessite pas de throws sur la signature de la méthode, et, par conséquence, n'obligera pas de catch dans le code appelant. Ce qui n'empêche pas de le faire éventuellement (mettre le throws explicitement).

Eclipse m'oblige à ajouter "throws ParseException".

Tu peux écrire ta redéfinition de méthode comme suit, ce qui te permettra d'éviter le throws ParseException:

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
try {
   // ton code
} catch(ParseException e) {
   throw new IllegalArgumentException(e);
}

[austin57]

Bonjour,

Et Merci à vous joel.drigo.
C'est exactement le terme dont j'avais besoin pour saisir le problème...unchecked exception!!!
Maintenant que je connais la différence checked/unchecked exception, c'est limpide.

Encore merci!

[professeur shadoko]

pour simplifier: il y a deux catégories d'exceptions: celles qui relèvent du "comportement normal" d'une application et celles qui relève du bug.
exemple de comportement "normal": dans les spécifications d'une gestion d'un compte en banque, on crée une exception pour dire qu'on a dépassé le découvert autorisé. Ici on doit capter l'exception (checked exception)
exemple de comportement "anormal": on a un bug qui déclenche un NullPointerException. Ici on ne peux pas nécessairement tout prévoir et on n'est pas obligé de capter l'exception.
Après ça peut devenir délicat: un erreur sur un format de nombre appartient-t'il à une catégorie ou a une autre? (C'est là qu'on décidera entre NumberFormatException ou une autre exception "métier")
Le principe général est assez délicat et mériterait des développements plus avancés sur la notion de "contrat" entre code appelant et code réalisant.
mais bon commençons par du simple.

[austin57]

J'ai consulté quelques sites sur le sujet
La gestion des erreurs est effectivement plus complexe que prévu :p Notamment avec toutes ces classes qui héritent des autres. Mais c'est intéressant.

D'ailleurs, en "jouant" avec les exceptions, une question m'est venue.
Je vais créer un sujet pour cette question qui bien que parlant d'exception et plus lié à la pratique et j'aimerais bien avoir l'avis de personnes expérimentées.

Alors à bientôt ^^
Damien