Avis sur les exception

Bonjour,

je voudrais avoir un avis d'une personne qui connait bien le language java.

Je voudrais savoir s'il est mauvais d'utiliser toujours throws Excpetion au lieu de try ... catch.

Si on utilise try... catch je pense qu'il n'y a pas besoin de throws Exception. Dans le catch la plupart du temps je fais e.printStackTrace ou e.getMessage avec System.out.println

Merci pour vos réponses

bonjour,
throws exception ne fais fais que renvoyer l'erreur plus haut dans l'application. elle ne dispense pas d'utiliser le groupe try catch.
Son utilisation permet d'augmenter la lisibilité de ton code, pour ne pas gérer des erreurs a tout les niveaux.
L'interception d'une exception peut te permettre aussi de lancer un nouveau traitement. printStackTrace ne sert que pour le debuguage lors de la conception (voir pendant l'utilisation).

Comme le dit bygui, printStackTrace n'est pas la seule chose à faire quand on catch une exception, en règle général il y a un traitement particulier à faire. (remontée d'une erreur à l'utilisateur via une popup, arrêt de l'application, tentative de connexion à un serveur, ...) C'est pour cela qu'il est important de gérer l'exception au bon niveau, ce que permet de faire throw.

ajountons que, mettre sur une méthode "throws Exception" est très mauvais, car là tu déclare indistinctement tout le panel d'exception existant, l'appelant n'a aucun idée de l'exception réelle que tes méthodes seraient sceptible de renvoyer. Quand tu décide de faire remonter des exception (ce qui est courant et normal), il faut mettre des directive throws qui visent explicitement ces types d'exception, pas des types parent trop généraux. Exemple, un méthode tu utilise pour gerer un fichier serait suceptible d'avoir des erreurs d'IO (mauvais fichier, mauvaios format, etc) ou des erreurs d'état (exemple théorique, on a pas encore défini sur quel fichier travailler ni sur quel format travaille). Ta méthode déclarerais alors "throws IOException, IllegalStateException".

Ne jamais oublier, dans la javadoc, de mentionner pour chaque exception dans quel cas elle peut etre levée :)

Perso, quand j'ai plus de 5 exceptions throwsées, je mets throws Exception, point barre. Cela n'empêche nullement un appelant de catcher une exception en particulier.

Je considère en effet que, à partir d'un certains nombre d'exceptions, la méthode peut avoir un comportement si varié qu'il vaut mieux assumer cette variabilité. Cela veut dire : Débrouillez-vous, je peux faire n'importe quoi. Par exemple, un test junit fait souvent ainsi (chez moi, tout le temps), et cela me parait bien justifié.

Après, évidemment, si ce procédé est génant, alors je crée une exception métier, comme on dit. :frenchy:

J'ai travaillé avec des api qui lancaient parfois 10 exceptions sur la même méthode.... Franchement c'est du n'importe quoi :) Mais si j'avais vu à la place un 'throws Exception' là j'aurais fait un jaunisse ...... Tu sais pas ce que çà lance, et si tu fait un 'catch (Exception e) tu te chope aussi toutes les runtimeException que t'as peut etre pas envie de catcher....

LE cas de junit est particulier car, là, la règle est inversée, c'est l'appelant qui, sans connaitre au départ la méthode, l'autorise à renvoyer tout est n'importe quoi (en gros tout ce qui est pas exception junit est traité comme un failure). Et, effectivement, dans ce cas, les méthodes test peuvent renvoyer ce qu'elles veulent.

Comme toujours, peser le pour est le contre. Je suis personellement contre le throws Exception pour les méthodes d'api publique (utilisable par d'autres développeurs ou sois meme)

Et aussi que penses-tu du Callable.call() throws Exception ?

Enfin bon... je voulais juste signaler que la règle Pas de "throws Exception" avait ses... exceptions.

Comme je disais, c'est l'appelant dans ce cas qui a décidé qu'on pouvait lancer tout et n'importe quoi :)

Je suis d'accord sur le fait que le throws Exception est immonde. C'est complètement ingérable pour celui qui utilise l'API.

Par contre, il a effectivement des cas où l'on est obligé de s'en servir comme par exemple avec les interfaces (comme la montré gifffftane). Parfois, on ne veut pas limiter l'implémentation à un seul type d'exception donc on laisse le choix. Ça n'empêche pas que les classes qui vont implémenter cette méthode de ne lançer que les exceptions nécessaires.