[Résolu]Assertions vs. Exceptions

[windu.2b]

Bonjour à tous,

alors voilà : depuis quelques jours, je me pose une question simple mais dont je n'arrive pas à trouver la réponse. Vos lumières m'intéressent donc au plus haut point (bon si avec tout ça, je n'ai pas capté votre attention...).

Selon vous, dans quels cas devrait-on avoir recours aux assertions et dans quels autre cas aux exceptions ?

Les assertions semblent être tout particulièrement utiles dans les "pré-conditions", qui consistent à vérifier avant toutes choses, que les valeurs reçues sont cohérentes.

Donc jusqu'à présent, je me démerdais avec les exceptions, levant une "NullPointerException" ou une "IllegalArgumentException" (vu que je code en Java, mais cette discussion est indépendante du langage utilisé) lorsqu'une méthode recevait une valeur 'null' là où cela ne devait jamais être le cas (cas typique : les 'setters').

Ce que je fais avec des exceptions devraient-ils en fait être fait à coups d'assertions ?

Ce qui transformerait ceci :

public void setXXX( XXX x )
{
if( x == null )
{
throw new NullPointerException( "bla bla bla" );
}

this._x = x;
}

en cela :

public void setXXX( XXX x )
{
assert x != null : "bla bla bla";

this._x = x;
}

Certes, le code s'en trouve raccourci, mais est-ce vraiment le seul intérêt ?

[Sentinel]

Les assertions et les exceptions ont deux buts différents.

Premièrement, les assertions doivent être explicitement activées à la compilation et au runtime pour fonctionner (-ea), tu ne peux donc pas compter sur leur présence au runtime pour effectuer des vérifications. Les exceptions au contraire, ne peuvent être désactivées, et sont donc un bon moyen de contrôle à l'exécution.

Ensuite, les assertions lèvent des Errors, comme la JVM (OutOfMemoryError...). Ce qui te donne un indice sur leur utilisation : elles servent uniquement à vérifier des conditions techniques "internes", non exposées au client (client au sens large : méthode appelante...). On se sert donc des assertions pour vérifier le comportement interne d'une classe utilitaire ou d'un framework lors de sa mise au point ou débuggage : par exemple, pour vérifier que la taille d'une collection est 0 après avoir effectué un clear(). Les exceptions au contraire, sont tournées vers l'utilisateur : elles permettent de signaler un cas particulier, et lui permettre d'y réagir le cas échéant. La vérification de préconditions (comme la nullité d'un paramètre dnas ton exemple) est du domaine des exceptions de type runtime (cf. prochain paragraphe).

Pour finir, au sein des Exceptions, il faut savoir distinguer les RuntimeExceptions (héritant de RuntimeException) des "checked" Exceptions (héritant d'Exception tout court). Une bonne pratique consiste à utiliser les exceptions "checked" uniquement pour les situations récupérables (réessai ultérieur, basculement en mode dégradé...), et les exceptions non vérifiées (runtime) pour les erreurs de programmation, par exemple une violation de préconditions (paramètre null ou mal formaté, état de l'application incorrect...). L'emploi de trop nombreuses exceptions "checked" alourdit inutilement le code.

Si tu veux creuser la question, plusieurs chapitres y sont consacrés dans "Effective Java" ("Java efficace" en Français) de Joshua Bloch.

[windu.2b]

Merci beaucoup Sentinel, je pense que j'ai la réponse à ma question

Et je vais me renseigner à propos du livre dont tu parles