Conseils sur la gestions des erreurs en Java

**Clorish** · 26/03/2008, 11h15

Hello

J'aimerais avoir vos conseils d'experts sur la gestion des erreurs en Java .... conceptuelement parlant

Visiblement elles sont geres a base d'exceptions mais utilise ton des exceptions pour tout ?

j'ai une classe, responsable de la generation de données dans un fichier. elle se decoupe de la sorte :
- 1 methode "Open" pour ovrir le flux d'ecriture
- N methodes "SetXXXParameters" pour affecter mes parametres de base
- N methode "write" qui gerer l'ecriture des données basée sur les parametres d'initialisation.
- 1 methode "close" qui gere la fermeture du flux.

Lors de l'affectation des parametres, j'effectue certaines operations :
- Conversion String -> Int (numberformatException)
- Test de nulité des chaines
- Test de chaines vides
- ...

Question 1 : Comment ce genre de tests ? Lancer une Exception type "ParametreInvalide" ?

ensuite j'ai donc plusieurs methodes basée sur des valeurs issues de l'initialisation de la classe lors de l'affectation des aprametres.

Question 2 : Si l'utilisateur n'a pas initialisé tous les parametres, la generation va echouer, donc test en amont de la validité des variables manipulées.
Si erreur : Exception ?

De maniere generale, quand lancer une excetion ? quand gerer un retour boolean de succes ou d'erreur (ou code d'erreur) ? Quels autres moyent java met a la disposition des utilisateurs pour gerer les erreurs de leurs programmes ...

sujet certe vaste ... mais quelques pistes de depart serait bien.
Le but est surtout d'acquerir une certaine facon de penser son application.

[Edit]
Petite precision : J'ai du mal a cerner quand on doit tester et retourner uen erreur, quand on "suppose" que les données sont bonne, quand on effectue des tests au preable et quand on tente l'ecriture quitte a se frapper une erreur du genre "NumberFormatException" ou "NullPointerException" ....

**adiGuba** · 26/03/2008, 13h47

Salut,

Perso je préfère de loin remonter une exception que de retourner une valeur de retour qui n'apporterais aucune information....

Imagine que tu ais à définir 50 paramètres :

Code :

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

1
2
3
4
5
6
7
8
9
MonObject o = new MonObject();
o.setXXX1();
o.setXXX2();
...
o.setXXX50();
 
if (o.write()==false) {
    System.out.println("Erreur ?");
}

Si jamais te te retrouves avec une erreur cela devient un gros "bordel" pour retrouver l'origine du problème...

Avec une exception tu pourrais avoir un message clair et précis (sans oublier le stacktrace).

Je pense que la question à se poser est plutôt : checked-exception ou unchecked-exception ?

Les checked-exceptions doivent obligatoirement être traitées (ou remontées à la méthode appelante). Cela permet d'obliger les utilisateurs de la classe à prendre en compte l'exception. C'est par exemple le cas des IOException...
Les unchecked-exceptions non pas besoin d'être traitées, et hérite (directement ou non) de RuntimeException. Du coup on peut très bien utiliser la méthode sans try/catch ni throws supplémentaire. En contrepartie si l'exception survient le programme plantera, mais cela permet une utilisation plus souple des méthodes dans le cas où il s'agit vraisemblablement d'une erreur de développement, tout en conservant la possibilité de la catcher si besoin. C'est par exemple le cas de NullPointerException...

a++

**Clorish** · 26/03/2008, 14h16

ok merci pour ces infos.

Donc si je saisi bien : Toutes les erreurs issue d'une mauvaise utilisation de l'applciation par son utilisateur final est supposée etre de type "Unchecked".
Genre on demande au gars de saisir un nombre et ce benet saisis une chaine textuelle

De meme, les erreur liés a une mauvaise gestion de la classe. Par exemple la methode B s'appuie sur des variable dont les valeurs dependent de l'execution d'une methode A. Si le programmeur fait ce qu'il faut (appel de A avant B) il n'y a pas de raison qu'il y ai une erreur, donc on met ces exception (verification des valeurs avant execution de la methode B) en "Unchecked".

Les exception de type "checked" seront donc toutes les erreurs d'execution independente de la volonte de l'utilisateur et du programmeur. Genre "j'ai bien fait tout ce qu'il faut, mais bon l'informatique n'est pas une science exacte et ca plante". Par exemple, une rupture de la connection internet en cours de traitement, ou un fichier attendu non trouvé, etc ...

Autre question : Les exception de type "Runtime" (unchecked) sont traitees par le developpeur ? ou bien on les laissent peter a l'ecran ?
Ceci dit, petent elles vraiement .... une fois remontée a la JVM ?

J'ai encore un peu de mal dans la gestion des exceptions.

Sinon tu es plutot pour la multiplication des exceptions dont le nom expime la cause ? ou des exceptions generiques dont on renseigne un message indiquant la cause ?

D'ailleur, a ce sujet : Le message ne sert que pour les traitements (catch) ou bien il est egalement géré par la JVM si l'exception remonte jusqu'a elle ?
Sous delphi le message affiché etait le message donné a l'exception ...

**adiGuba** · 26/03/2008, 15h10

Les mauvaises saisies utilisateurs peuvent être considéré comme une checked car il faut traiter le cas.

Grosso-modo on peut considérer que les checked-exceptions sont récupérable (demander une autre saisie, réessayer la connexion réseau) tandis que les unchecked ne sont pas récupérable (nullpointer, valeur incorrect...).

Maintenant il y a certain cas où on est à la limite des deux. Par exemple lorsqu'on vérifie des données :

Si les données proviennent de l'utilisateur on devrait utiliser une checked exception.
Mais si elles viennent du développeur (en dur dans le code) ce serait plutôt une unchecked...

Dans ce cas perso j'utilise une unchecked que je traite dans le cas où il y a une saisie utilisateur (car on peut bien sur traiter une unchecked dans un try/catch)

Envoyé par Clorish

Autre question : Les exception de type "Runtime" (unchecked) sont traitees par le developpeur ? ou bien on les laissent peter a l'ecran ?
Ceci dit, petent elles vraiement .... une fois remontée a la JVM ?

Les unchecked peut tout à fait être traité dans un try/catch, mais si ce n'est pas le cas elles remontent jusqu'à l'origine du thread et le plante méchamment (et éventuellement l'application tout entière si elle est mono-threadé).

Donc grosso-modo tu as deux choix :

Traiter l'exception et gérer les mauvaises valeurs, comme si c'était une checked-exception.
Laisser le programme se planter, dans le cas où tu es sûr que l'exception ne surviendra pas.
Cela peut sembler bizarre mais c'est un bon choix : tu ne t'embête pas à traiter une exception dont tu n'a que faire, mais si par le plus grand des malheurs en modifiant ton code ton exception survient, tu auras de suite une joli exception concrête et bien explicite

Envoyé par Clorish

Sinon tu es plutot pour la multiplication des exceptions dont le nom expime la cause ? ou des exceptions generiques dont on renseigne un message indiquant la cause ?

Les deux mon colons !
En fait c'est pratique d'avoir une arborescence d'exception. Si tu prends le cas des erreurs d'entrée/sortie :

On a une exception mère IOException qui permet de traiter toutes les exceptions d''entrée/sortie.
Et plusieurs exceptions filles qui gère des problèmes bien spécifique, comme par exemple FileNotFoundException lorsqu'un fichier n'existe pas, ou SocketException pour des problème réseaux. Le tout contenant un message explicite.

Le message peut être destiné aux utilisateurs pour signaler le problème. Quand aux différents types, ils peuvent être utilisé pour spécifier des comportements différents, par exemple :

Code :

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

1
2
3
4
5
6
7
8
9
10
 
try {
   ...
} catch (FileNotFoundException e) {
   // Le fichier demandé n'existe pas
   // => On demande à l'utilisateur de choisir un fichier existant
} catch (IOException e) {
   // Autre erreur de lecture
   // => On affiche un message d'erreur
}

Envoyé par Clorish

D'ailleur, a ce sujet : Le message ne sert que pour les traitements (catch) ou bien il est egalement géré par la JVM si l'exception remonte jusqu'a elle ?
Sous delphi le message affiché etait le message donné a l'exception ...

Le message des exceptions est affiché dans le stacktrace.

a++

**Clorish** · 26/03/2008, 15h21

Merci pour cette grand explication.

J'ai fait mon chemin en attendant et j'en suis arrivé a une conclusion que tu confirme.
En fait toutes les verifications de parametres sont des RuntimeException car elles ne sont pas sensé arrivée si le developpeur fait son travail comme il faut.
Si il oublie effectiement il est rappelé a l'ordre directement.

En fait, pour resumer la chose, les RuntimeExceptions sont des erreurs qui ne sont jamais sensé arriver. si elles surviennent c'est pendant la phase de developpement et sont sensé etre corrigé avant la phase d'exploitation.
une sorte d'assertion en quelque sorte.

**adiGuba** · 26/03/2008, 15h46

Envoyé par Clorish

En fait, pour resumer la chose, les RuntimeExceptions sont des erreurs qui ne sont jamais sensé arriver. si elles surviennent c'est pendant la phase de developpement et sont sensé etre corrigé avant la phase d'exploitation.
une sorte d'assertion en quelque sorte.

Pas exactement : les RuntimeException peuvent tout à fait arriver... et même souvent

En fait cela laisse au développeur le choix de décider s'il doit la traiter ou si elle ne devrait pas arriver.

Prenons le cas de Integer.parseInt() qui renvoi un NumberFormatException (qui est unchecked), et le code suivant :

Code :

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

int value = Integer.parseInt(string);

Doit-on utiliser un try/catch ?

Si la "string" vient d'un fichier de configuration on pourrait s'en passer il n'y a rien de vraiment gênant à remonter une vilaine exception et tout planter
S'il s'agit d'une saisie utilisateur, il est préférable d'utiliser un try/catch pour éventuellement demander de resaisir la valeur correctement.

Les uncheckeds sont plus souple

a++

**Clorish** · 26/03/2008, 15h55

ok j'y voit un peu plus clair.

Maintenant viens un autre probleme : La gestion de l'enchainement des appels des methodes.

Ma classe est initialisée par 3 methode suite a laquelle on appele la methode de generation qui se base sur le resultat de ces 3 methodes.

J'ai bien tester la validité des parametres de chaques methdoes d'initialisation mais comment gerer l'execution successive des ces methodes.
Genre le gars a "oublié" un de ces appels.

Je precise le cote "obligatoire" lié a l'execution de ces methodes. Je ne peut pas me baser sur des "valeurs par defaut" si un de ces parametres n'est pas saisi.

[Edit] En fait je me pose la question de la legitimité de tester autant que ca mes parametres ....
est il conrrect de "supposer" que le developpeur utilise ma classe convenablement et laisser peter les NullPointerException, les NumberFormatException si il transmet des parametres null, ou des chaines a la place d'entiers, et reporter le test de validité de ces parametres en amont lors de la saisie ou du chargement du fichier de config ?

En resumé, doit on traiter les erreurs de developpement du gars qui fait n'importe quoi et qui a pas lu la javadoc ?

Parce que je crois qu'en fait je cherche a trop securiser mon application.