Discussion :

[picomz]

Bonjour,
Je me suis enfin décidé à essayer d'utiliser correctement le système d'exception de java, mais je ne suis pas sur de l'utiliser correctement...

Pour l'instant je pensai en fait généré une liste d'exceptions, partant de l'exception la plus précise, par exemple un ArrayIndexOutOfBounds, puis redescendre dans chacune des fonctions en générant une exception plus générale, jusqu'à arrivé au moment ou je traite complètement l'exception.

Je voudrais utilisé ce système car si je traite uniquement un ArrayIndexOutOfBounds, je ne suis pas sur que cela voudra dire grand chose pour l'utilisateur, de plus je voudrai pouvoir continuer le traitement d'une fonction même si une exception c'est produit lors de son traitement sans pour autant affiché tout de suite un message d'erreur à l'utilisateur.
Je précise aussi que j'enregistrerai dans un fichier de log chacune des excptions qui aura été généré pour que l'utilisateur puisse retrouver d'ou proviens l'erreur.

Je sais pas si c'est très clair donc je vais prendre un exemple de traitement :
L'utilisateur demande une fonction de diagnostique, cette fonction effectue différent traitements par exemple une requete dans une base de données et lecture dans un fichier. Si j'ai une erreur dans ma base de données, je voudrai arreter ce traitement, mais il n'y a pas de raison que la lecture dans le fichier ne fonctionne pas. Je ne veux pas non plus afficher un popup d'erreur à l'utilisateur car si j'ai une erreur pour le fichier aussi, (puis pour les x autres traitements suivant) cela risque de l'agacer. Il faudrai donc juste un popup pour l'avertir qu'une erreur c'est produite dans la fonction diagnostique, et l'inviter a consulter les logs pour plus de détails.

Bon voila, c'était mon idée pour l'utilisation des exceptions, mais je ne sais pas du tout si c'est une bonne manière de faire, ou s'il y'a d'autres méthodes. Je n'ai pas du tout trouvé de tutorial sur le net qui expliquai comment vraiment gérer les exceptions (A par qu'il faut faire un try catch...) donc si quelqu'un peu me donner son avis j'en serai très reconnaissant. (Et puis aussi merci d'avoir tout lus...)

Merci d'avance.

[winnux]

il n'y a pas que le try ... catch.
Pense au finally ce sera meilleur pour ce qui concerne les fermeture de flux

Code :

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

1
2
3
4
5
6
7
8
9
 
try {
    try {
 
    cacth ...{ 
    }
 
} finally {
}

mais adiguba explique cela mieux que moi dans un post...recherche sur forum

@+

[thibaut]

Il faut utiliser des blocs try... catch ... finally comme suit:

Code :

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

1
2
3
4
5
6
7
8
try {
}
catch (<TypeException> e) {
  // Logger l'exception et la renvoyer si nécessaire
}
finally {
  // ... Liberére les ressources
}

Le plus simple est de définir deux types d'exceptions:

ExceptionUtilisateur qui étend Exception
et

ExceptionTechnique qui étend RuntimeException,

comme cela tu n'as besoin de catcher ExceptionTechnique que si nécessaire et éventuellement renvoyer une ExceptionUtilisateur si tu veux que l'utilisateur soit informé de cette erreur.

[picomz]

Pour le finally je connais, mais je pense pas que c'est cela dont j'ai besoin. C'est pas un problème de ressource à libérer ou d'action à éxecuter dans tout les cas.

Pour le RuntimeException je vais m'en servir pour poursuivre l'éxécution de la fonction même si une exception est survenus, mais en fait ce que je voulais surtout c'est avoir de l'aide pour la manière de traiter les exceptions.

Est-ce que vous faite un throw lorsqu'une exception surviens puis vous les catcher toutes au même endroit ? Est-ce que vous faite directement un try catch ? Une autre méthode ? C'est plus la dessus que j'ai des problèmes, pas sur l'utilisation des exceptions.

Vus que j'ai pas l'impression que d'autres personne se pose ce genre de question, ca doit être super simple mais je bloque.
Je précise aussi que mon programme est susceptible de lancer un grand nombre d'exception pour tout un tas de raison indépendante de ma volonté.

[KiLVaiDeN]

Salut,

Perso je trouve ça lourd le système d'exception de Java, surtout pour signaler des erreurs aux utilisateurs.

Je préfère largement une gestion personnalisée des erreurs; un objet "erreur" contenant le descriptif, la date, le lieu, l'utilisateur ( si besoin ) et inséré dans une collection au sein d'un autre objet collecteur. Ainsi, si l'utilisateur souhaite visualiser les erreurs applicatives, il peut le faire en exploitant ce "log mémoire".

Vous en pensez quoi ?

A+

[picomz]

Argh, faut pas me dire ca, deja que je me forcer à utilisé les exceptions...

Enfin en tout cas pour ce que tu dis je pense que c'est possible aussi de le faire en surchargeant la classe Exception, donc tu garde les mêmes fonctionnalité mais tu profite en même temps du système de gestion de java.

[KiLVaiDeN]

Argh, faut pas me dire ca, deja que je me forcer à utilisé les exceptions...

Enfin en tout cas pour ce que tu dis je pense que c'est possible aussi de le faire en surchargeant la classe Exception, donc tu garde les mêmes fonctionnalité mais tu profite en même temps du système de gestion de java.

Tu profites également de la lourdeur de celui-ci, et du temps de traitement necessaire au "lancement" d'une exception ( non négligeable ).

Alors que tu pourrais utiliser un système gardant tout en mémoire directement, et personnalisé, te permettant de faire des recherches, de le stocker, de créer des fichiers de logs, etc..

Je préfère en général me servir du système d'exception au minimum, parce que ça "coupe" le cheminement de la JVM, en tout cas j'en ai l'impression. Tu peux très bien imaginer une thread de gestion des erreurs, qu'en penserais-tu ?

[thibaut]

Absolument pas d'accord, mais bon chacun son point de vue. Tu sais on pourrait pousser les consiédrations plus loin et programmer en Java comme en C, parceque à la limite l'héritage et la POO c'est une perte de temps et ç alourdis le code en le rendant moins lisible... Et puis aussi à quoi bon utiliser les collections, moi je propose de revenir aux "bases" et utiliser les tableaux statiques...

Non en dehors de ces considérations, pour moi il faut utiliser les exceptions mais à bon escient, c'est à dire ne pas mettre des try... catch de façon systématique, mais plutôt de faire des throws dans la signature des méthodes et de traiter la plupart des exceptions au niveau le plus haut.

Sinon je ne pense pas que la gestion des excceptions ralentisse considérablement la JVM...

A+

[KiLVaiDeN]

A chaque fois que tu crées un objet Exception, tu regénères le stack à partir de la méthode en cours, ce qui est beaucoup plus couteux que l'insertion d'un objet dans une collection en mémoire. Ta trace mémoire est aussi beaucoup plus grande..

Tout dépend de ce que tu comptes faire au final. Je suis d'accord pour utiliser les exceptions dans certains cas, mais quand il s'agit d'erreur courantes et rapides à traiter, il n'y a pas besoin de mettre des exceptions à tout va, ça va tout ralentir, certes d'une manière que certains peuvent considérer négligeable, mais autant optimiser un petit peu si possible non ?

A+

[picomz]

Je suis d'accord avec toi KiLVaiDeN pour ce qui ai de ne pas utiliser des exceptions a tout vas, mais niveau performance je pense quand même que le cas ou un exception est généré reste assez exceptionnelle, donc cela ne doit pas trop jouer.

Sinon pour reprendre le sujet de base je pense que je vais m'y prendre un peu différement, je vais plutôt faire hériter toutes mes exceptions d'une exception de base, et ne pas lancer une nouvelle exception sur chaque couche mais plutot rajouter un message d'informations permettant de retrouver l'erreur.
Je me rend compte que c'est un peu un doublon par rapport à la pile d'exception de java mais cela ne contiendra pas vraiment les mêmes informations.