[Exception] de l'utilisation des exceptions...

Hello !

j'ai un problème philosophique avec java et les exceptions:

ex: j'ai un boite de dialog pour effectuer un login password et connection

Perso j'effectue des branchements conditionnels au module de log pour savoir 1 si le serveur est connection (client -serveur) et deux si le login-password est valide. Enfin je connecte si tout est valide.

on me conseille d'utiliser un mon d'exception du genre:

Code:

---

1 2 3 4 5 6 7 8 9 10

try{ connect(login, password, ip); }catch(ServerException e){ ... }catch(LoginException e){ ... }catch(PassWord e){ ... }

---

Qu'en pensez vous ?

PS: je suis peut etre pas dans le bon forum; mais c'est avant tout à des déveoppeur Java que je souhaite m'adresser

Merci pour vos réponse

Salut,


Cela me semble bien. Qu'est-ce qui te gène la dedans ?
A la rigueur tes trois exceptions pourraient hériter d'un même exception afin de permettre un traitement global des erreurs, par exemple si tes trois exceptions hérite de ConnectException tu peux également écrire :

Code:

---

1 2 3 4 5

try{ connect(login, password, ip); }catch(ConnectionException e) { ... }

---

a++

PS : j'ai rajouté les balises [ code ] dans ton message... merci d'y penser la prochaine fois ;)

J'ai une philosophie par laquelle les exceptions sont à utilisées comme erreur finales.

Dans l'exemple avec les catchs je me retrouve avec des post conditions pour poursuivre (fermer la boite de dialogue, lancer un thread pour un timer etc...)

J'ai perso tendance avec faire des pré condition (vérifier que le log et le password sont bons) avec une méthode spécificique qui renvoie un boolean etc...

Je n'arrive pas encore à envisager les avantages et incovénients de chacun.

J'ai l'impression qu'un bon code est un code qui n'envoi jamais d'exceptions, sauf erreur au niveau des controleurs etc...

Si d'autre ont un avi. C'est important pour moi je suis en discution pour une architecture.

PS: en plus simple faut il faire racine de x et récupérer un exception (x étant négatif) ou si x<0 then return racine(x). Le throwable étant fait pour le cas ou (sécurité).

A mon gout les exceptions servent surtout au bug tracking.

Perso, je suis d'accord avec toi, j'aime pas trop utiliser les exceptions pour faire des tests de validité... Je préfère vérifier mes formes avant, et gérer effectivement avec des booleens... Pour moi, si il y a une exception, c'est que l'execution s'est mal passée... Bien sur, il y a des cas ou tu n'as pas trop le choix, mais la philosophie tendant a gérer ses cas avec des exceptions me plait pas trop, a partir du moment ou je peux l'eviter...

Il y a des cas précis où gérer une exception est obligatoire et tu es en parti dans l'une d'elle : La connection.

Pour faire une nouvelle connection tu vas ouvrir une socket et les erreurs d'ouverture des sockets sont des exceptions : "Host not found", "No route to host", "TimeOut". Il ne te renverra pas de boolean mais bien une exception.

Le Pro_Fete.

Utiliser les exceptions te permettra de t'assurer que tu n'oublies pas de gérer un cas possible d'erreur.

Dans ton code :

Code:

---

1 2 3 4 5 6 7 8 9 10

try{ connect(login, password, ip); }catch(ServerException e){ ... }catch(LoginException e){ ... }catch(PassWord e){ ... }

---

si tu enleves la levée de LoginException et que tu utilises une vérification au préalable de l'existence de ton login, est tu sur de ne pas oublier par la suite cette étape à un autre endroit dans ton code ?
Peut être écris tu du code que tu es le seul à utiliser ? Les exceptions ne pourront pas être ignorées par un utilisateur de ton code.

On distinguera 2 types d'exceptions :
- checked exceptions : héritent d'Exception, représentent généralement des erreurs de fonctionnement dans l'appli (fonctionnelles) et peuvent représenter des types de retour alternatifs. Elles ne doivent pas être ignorées par le développeur.
- unchecked ou runtime exceptions : héritent de RuntimeException, réprésentent des erreurs techniques ou non récupérables. Elles peuvent être ignorées par le développeur mais pas par l'architecture.

Ce que je dis est sujet à discussion mais un consensus semble avoir émergé dans ce sens. Regarde par exemple :
- les transformations faites sur la gestion des exceptions entre les versions 2 et 3 d'Hibernate,
- la gestion des exceptions dans JDO
- la gestion des exceptions dans Spring

Citation:

---

Envoyé par Alec6

J'ai une philosophie par laquelle les exceptions sont à utilisées comme erreur finales.

---

Non, pour les erreurs finales il y a les RuntimeException ou les Error.
Les RuntimeExceptions pour les erreurs de programmations (NullPointerException, ArrayOutofBound...) et les Error pour les problèmes plus importants généralement envoyé par la JVM (OutOfMemoryError, StackOverflowError).

Les Exceptions sont des "conditions" que les applications peuvent vouloir gérer (mauvaises saisie utilisateurs, problèmes réseaux, etc...).

Citation:

---

Envoyé par Alec6

Dans l'exemple avec les catchs je me retrouve avec des post conditions pour poursuivre (fermer la boite de dialogue, lancer un thread pour un timer etc...)

---

Généralement avec un bloc try/catch/finally il est possible de faire cela très proprement... je ne vois pas trop le problème...

Citation:

---

Envoyé par Alec6

J'ai perso tendance avec faire des pré condition (vérifier que le log et le password sont bons) avec une méthode spécificique qui renvoie un boolean etc...

---

Quel différence ? La vérification se fait lors de la connection dans un cas comme dans l'autre...

Citation:

---

Envoyé par Alec6

Je n'arrive pas encore à envisager les avantages et incovénients de chacun.

---

Avantage des Exceptions :

• Riche en information (avec un message et eventuellement d'autre information).
  Elle oblige le developpeur à les traiter.
  Evolution plus facile : on peut facilement ajouter une exception différente sans impacter l'utilisation de la méthode.

Le seul avantage à l'utilisation d'un code de retour pourrait être au niveau des performances, mais il faut vraiment atteindre des cas extrêmes pour voir la différence : Exception & Performance. De plus cette différences n'est vrai que si l'on ne traite pas l'erreur car elle correspond à l'allocation/désallocation des Exceptions. Or si on traite correctement l'erreur il faudra quand même allouer des messages d'erreurs, etc...

De plus c'est nettement plus objet comme approche : le code de retour devient utile et n'est plus simplement utilisé pour la gestion des erreurs...

Citation:

---

Envoyé par Alec6

J'ai l'impression qu'un bon code est un code qui n'envoi jamais d'exceptions, sauf erreur au niveau des controleurs etc...

---

Non, un bon code est un code qui traite correctement toutes les exceptions des méthodes qu'il appelle (sauf si il déclare les renvoyer lui-même)...

Citation:

---

Envoyé par Alec6

PS: en plus simple faut il faire racine de x et récupérer un exception (x étant négatif) ou si x<0 then return racine(x). Le throwable étant fait pour le cas ou (sécurité).

---

Cela dépend de ta méthode racine(x). Si tu veux authoriser les valeurs négatives pour renvoyer la racine de la valeur absolut cela ne pose pas de problème (mais ce n'est pas forcément logique)...

Maintenant si racine(x) avec x<0 doit provoquer une erreur, tu as trois solutions :

• 1. Retourner un code d'erreur (par exemple -1).
  2. Retourner NaN (mais cela n'est possible que sur des Float et/ Double).
  3. Renvoyer une exception

Maintenant prend le calcul suivant :

Code:

---

double d = racine(x) * racine(y);

---

• 1. L'erreur n'est pas décelable facilement (il faut faire deux if() pour la détecter).
  2. Il suffit de vérifier que le résultat ne soit pas NaN (si un des membres d'une opération est NaN, alors le résultat est forcément NaN), mais on n'a pas de détail sur l'erreur à moins de faire des if() comme la solution 1.
  3. On obtient une belle exception, avec eventuellement un 'joli' message...

Personnellement je prefere la troisième solution... En effet la detection de l'erreur est plus simple et plus complète...

Citation:

---

Envoyé par Alec6

A mon gout les exceptions servent surtout au bug tracking.

---

Encore un avantage pour les exceptions : si tu traites les erreurs avec un code de retour, il va te falloir généré des messages d'erreurs selon ces codes de retour. Ce qui est très lourds à coder. Du coup on se retrouve avec des messages d'erreurs du style "Erreur code 165" !!!

Merci bien pour vos réponse à tous et pour ce petit cours adiGuba, dont la formule long a=racine(x)*racine(y) est convaincante.

Donc j'adopte le système de controle par exception.

Et je relance le sujet avec: Pensez vous qu'il soit interressant de logger les exceptions dès leurs instanciations (afin d'éviter les oublies, et prb des stagiaires). Je parle des exceptions faites maison