Discussion :

[tnarol]

Salut,

J'aimerais savoir quels grands principes appliquer relativement à la gestion d'exception en Java. Typiquement j'écris du code avec des appels de fonctions auxiliaires chacune susceptible de lancer des exceptions je ne sais jamais où placer le try/catch au niveau global ? au niveau le plus bas ? les deux ? ni quoi catcher nímporte quelle exception (Exception) ou bien la classe précise des différentes exceptions pouvant être lancées.

Merci de votre aide.

[Pill_S]

Il ne faut pratiquement jamais catcher "Exception", ou pire, "Throwable"

Exception fait que tu récupères toutes les exceptions possibles (les NullPointer, les IllegalArgument, etc.), Throwable ferait que tu récupères TOUTES les erreurs possibles (OutOfMemoryError, NoClassDefFoundError, etc.)

dans la pratique, les conseils sont généralement de lever des exceptions en rapport avec l'abstraction. Un DAO devrait lever uniquement des "DAOException", un service des "ServiceException", etc.

Typiquement, je me retrouve souvent avec des codes comme ceci:

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
 
class DAO {
  private Logger log = Logger.getLogger(DAO.class);
 
  Object get() throws DAOException {
    try {
      // pour une raison x ou y, il y a des IOException levées ici
    } catch(IOException e) {
      log.error("IOException during get", e);
 
      // on set la cause dans le constructeur, pour que les classes recevant 
      // cette exception puissent avoir plus d'informations en cas de besoin
      throw new DAOException("IOException during get", e);
    }
  }
}

Concernant les types, bien que le débat soit ouvert, je conseille les RuntimeException pour les erreurs de programmation (lorsqu'on appelle une méthode avec un paramètre invalide p.ex.), qui, moyennant une utilisation correcte de l'api, ne sont jamais levée, et Exception partout ailleurs.

[tnarol]

Merci beaucoup, ca semble en effet une bonne facon de procéder.

J'ai tendance à beaucoup utiliser catch (Exception e) car d'une part j'utilise du code tiers qui lance cette classe d'exception et d'autre part par souci de simplicité : à partir du moment où quelque chose ne s'est pas bien passé souvent ca m'est un peu égal de savoir précisément l'origine. En gros je trouve que ca permet de ne pas trop se prendre la tête là où il n'y a pas besoin...

Par ailleurs je remonte rarement les exceptions catchées au niveau superieur avec un nouveau throw comme toi.

Est-ce que ce sont des erreurs ? Est-ce dangereux ? Je crois que j'ai besoin de comprendre la philosophie du truc qui est sûrement plus complexe que le simple fait d'éviter que ca crashe.

[JoeChip]

L'utilité, c'est aussi trouver facilement une erreur quand elle se produit... Dans le cas extrême, tu met "try" au début d'une énorme méthode, et "catch (Exception e){}" à la fin. S'il y a un souci, tu ne seras même pas au courant, mais tu verras que ton appli ne marche pas comme prévu, ailleurs dans le code... Donc ça finira par crasher sur une erreur incompréhensible pour toi et pour l'utilisateur, avec s'il le faut des fichiers ou des bases de données laissés dans des états imprévus...

Alors que si tu contrôle finement les Exceptions, tu peux avoir 1) un message d'erreur à l'usage de l'utilisateur 2) ton appli qui reste dans un état prévu 3) un log avec l'erreur et les valeurs des variables au moment où elle s'est produite. 4) faire un rollback des transactions (annuler les modifications dans une BD) affectées.

[Pill_S]

Est-ce que ce sont des erreurs ? Est-ce dangereux ?

des erreurs, non... mais bon... faut savoir si la responsabilité d'une gestion complète des exceptions se fait dans la classe actuelle ou non...

le fait d'encapsuler dans un nouveau type (DAOException au lieu de IOException) permet de mieux rendre compte des couches dans lesquelles surviennent les problèmes, mais dans mon exemple ça ne sert pas à grand chose. C'est utile à partir du moment où cela ajoute de l'information (mon message "IOException during get" n'ajoute pas grand chose, et donc n'est pas réellement utile)


après tout est discutable... mais ce pattern est de loin pas le plus mauvais qui soit

[tchize_]

evite quand meme le catch(Exception e), en faisant ça tu surprotège ton code, et empeche certaines exceptions, qui devraient remonter de remonter. Par exempe les RuntimeException qui ne devraient normalement pas survenir en exécution "normal" et son souvent un signe d'un problème non récupérable.