Discussion :

[DavidleVrai]

Bonjour à tous,

Suite à un débat légèrement animé à mon travail, je viens solliciter votre avis sur la question suivante :

Est-ce une bonne pratique de lever des exceptions dans le constructeur d'une classe en Java ?

J'ai fait plusieurs recherches sur le sujet et je trouve des avis opposés. Si vous pouvez me donner les pour et contres de cette pratique, ça me permettrait d'avoir un avis plus factuel sur le sujet.

Merci d'avance pour votre aide et à bientôt

[professeur shadoko]

Est-ce une bonne pratique de lever des exceptions dans le constructeur d'une classe en Java ?

ben oui ... si on te passes des arguments qui ne permettent pas de construire l'objet correctement.
deux cas:
- violation du contrat défini par la signature: IllegalArgumentException (ou des exceptions apparentées) la faute est du ressort du code appelant
- impossibilité qui n'est pas du ressort du code appelant: exception contrôlée (le code appelant n'a pas les moyens de vérifier a priori si ça va marcher)

[OButterlin]

Pareil pour moi, si on peut détecter une incompatibilité dès la construction de l'objet, pourquoi se priver d'une exception ?
Généralement, l'argument contre est l'obligation de mettre le code dans un bloc try catch... autant dire qu'il n'y a pas d'arguments contre
Enfin, je dis ça mais en fait, je n'ai jamais entendu quelqu'un s'offusquer de la possibilité d'avoir une exception dès la construction d'un objet... c'est quoi les arguments contre ?

[PhilippeGibault]

Selon la bible des bonnes pratiques (https://www.amazon.fr/Effective-Java...FXXACDS1TF85HE), on doit utiliser les exceptions "standards" pour les erreurs liées à l'utilisateur et les "Runtimes" pour les erreurs de programmations.

Après, rien n'empêche, en appliquant ces règles, de jeter une exception à la création de l'objet.

Je dirais même que c'est mieux de ne pas créer l'objet si celui-ci n'est pas créé.
Du coup, comme l'erreur est lié à l'utilisateur (il ne donne pas les bon paramètres), il faut utiliser un exception standard.

[professeur shadoko]

Du coup, comme l'erreur est lié à l'utilisateur (il ne donne pas les bon paramètres), il faut utiliser un exception standard.

attention : la recommandation est un peu ambiguë (une exception "standard" ) :
si les paramètres d'appels sont vérifiables par le code appelant alors c'est de la responsabilité du code appelant ... et donc une RuntimeException
sinon une exception contrôlée (donc quand le code appelant n'a pas les moyens de faire les vérifs)
Pourquoi cela? et bien si le code appelant fait les vérifications demandées et est sûr d'être conforme aux contrat d'API il serait un peut fort de café de lui demander en plus de faire un try/catch d'une exception contrôlée (checked exception)!
S'il ne les fait pas c'est pour sa pomme: violation de contrat d'API!

Remarque: le code appelant peut aussi volontairement faire un try/catch d'une RuntimeException parce qu'il a la flemme (ou pas l'opportunité) de faire la vérif (exemple courant: NumberFormatException).

Il est de bon ton de préciser dans la javadoc quelles sont les exceptions claquées si violation du contrat d'API (en plus des exceptions contrôlées).

Mais pour revenir à la question initiale: il est impensable d'avoir des objets incohérents, il ne faut pas autoriser leur création! ergo: il est impératif d'avoir des exceptions propagées par les constructeurs ... après la discussion est de savoir si ce sont des sous-classes de RuntimeException ou pas.

[openlowcode]

Bonjour,

je ne vois pas de raisons de ne pas mettre d'exceptions dans un constructeur. Je le fais souvent pour des vérifications que les données d'entrée du constructeur sont cohérentes. Quand ce n'est pas cohérent, je balance des "RuntimeException". J'ai mis du temps à comprendre que c'était la bonne pratique, mais cela allège vraiment le code.

Ensuite, je laisse les RuntimeException remonter jusqu'à un haut niveau (par exemple le moteur d'exécution des actions métiers sur mon serveur), et c'est cette couche-là qui va se charger de prévenir le client que la transaction a échouée.

Faire des try-catches à plusieurs étapes est généralement une mauvaise pratique à mon avis, cela alourdit le code, et on perd souvent même en traceabilité.