Discussion :

[grunt2000]

Bonjour,

Le mot clef assert est très utile en Java pour construire du code "blindé". Cependant, il a un défaut, même utilisé à bon escient (par exemple, pour valider le contenu d'une méthode privée ou dénoncer un fait de programmation non respecté), c'est qu'il peut, en levant son Error, mettre en instabilité l'application. C'est potentiellement le cas notamment, lorsqu'elle est déployée sur un serveur d'applications ou web, parce ce que ces derniers ne vont pas nécessairement pouvoir exécuter tous les gestionnaires qu'ils devraient à l'issue de cette erreur, comme ils l'auraient fait si c'était une Exception.

Cela est normal car une Error provoque une demande de tout arrêter en urgence et immédiatement. Les conséquences sont donc parfois un peu trop lourdes. De fait, il peut y avoir des effets désagréables à la suite de la levée de cette Error.

L'utilisation de la classe Validate (de l'API Commons Lang d'Apache) est un choix alternatif intéressant car cette cette classe permet de lever, entre autres, une IllegalArgumentException, qui convient souvent mieux. Et parce qu'elle n'est pas débrayable, elle assure de faire son contrôle tout le temps, a contrario d'assert qui ne fonctionne que si l'exécutant a placé -ea dans sa ligne de commande Java (ce qui n'est pas si fréquent, surtout lorsqu'il ne sait pas qu'il doit le faire !)... Or, un code de contrôle qui ne s'exécute pas, c'est évidemment un code de contrôle qui ne sert à rien.

Pour exemple, j'avais une masse d'assert faits ainsi :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

assert(toto != null) : "mon message";

Sous Eclipse, cette recherche (en mode expression régulière) :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

assert\((.+) != null\) : "(.+)";

et cette chaîne de remplacement :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

notNull($1, "$2");

m'ont permis de faire le remplacement rapidement.

Bien sûr, j'ai dû ajouter une directive import dans mes sources.

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

import static org.apache.commons.lang3.Validate.*;

A mon sens, bien que les utilisateurs d'assert ne soient pas si nombreux, ce mot-clef sauve pourtant presque autant que les tests unitaires. En tout cas, il aide à donner confiance dans un code que l'on lit...

Voilà ! Si vous avez d'autres solutions, n'hésitez pas à les partager.

Grunt.

[adiGuba]

Salut,


Sinon à partir de Java 7 on peut utiliser Objects.requireNotNull...


a++

[thelvin]

Juste pour rappel, assert ne sert pas à valider les inputs extérieurs, sur lesquels on a aucun contrôle et qui peuvent être mauvais sans qu'on se soit trompé nulle part. Auquel cas il faut juste remonter la petite erreur "c'est n'importe quoi ce que vous avez tapé là," c'est normal.

assert sert à vérifier les conditions internes, ce qu'on suppose être vrai parce que notre programme est censé s'être assuré que c'est vrai. Dans le cas où c'est faux c'est une grave erreur interne et il n'y a rien à tenter, tout est fini.

[tchize_]

Sinon, bien que les utilisateurs d'assert ne soient pas si nombreux, ce mot-clef sauve pourtant presque autant que les tests unitaires. En tout cas, il aide à donner confiance dans un code que l'on lit.

Comme dit thelvin, ce mot clé sert à vérifier ce qui ne peux pas être. Si le assert s'évalue à false, c'est effectivement une erreur grave.

Pour ce qui est des gestionnaires qui attrapent Exception et pas Error, ce n'est le cas que si on code mal, suivant ce genre de pattern:

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
try{
} catch (Exception e){
}

En effet, on ne dois catcher que les Exceptions qu'on est capable de traiter, et pas y aller à l'aveugle.

Le nettoyage doit se faire dans un pattern

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
try{
} finally {
}

et, éventuellement, si un traitement générique des cas d'erreurs, par exemple un ThreadPool qui doit continuer à fonctionner même si une tâche a échoué, le pattern est le suivant:

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
try{
} catch (Throwable t){
}

Les assert n'ont rien à voir avec les tests unitaires, et mettre un assert ne dispense pas de créer des tests unitaires.

Enfin, n'oublions pas qu'un assert ne fait rien par défaut, les assertions sont désactivées par défaut sur la JVM !

[grunt2000]

Ah, il faut que je précise.
Je suis absolument d'accord avec tous vos arguments !

Mais,

j'ai constaté que quand un assert saute, alors qu'il se trouve au sein d'un ear déployé dans un JBoss ou Glassfish, il est fréquent que ce serveur d'application qui n'est pas parfaitement blindé de tous les côté face aux Error, se mette à son tour à coincer. Par exemple : il ne sera plus capable de faire le hot deploy suivant, pour un motif ténébreux, s'il ne bloque pas parfois entièrement. Un assert qui saute en plein milieu d'un EJB qui était invoqué lui-même par un autre EJB, souvent rend le serveur d'application instable.
Il est juste là mon problème.

Juste pour rappel, assert ne sert pas à valider les inputs extérieurs, sur lesquels on a aucun contrôle et qui peuvent être mauvais sans qu'on se soit trompé nulle part. Auquel cas il faut juste remonter la petite erreur "c'est n'importe quoi ce que vous avez tapé là," c'est normal.

assert sert à vérifier les conditions internes, ce qu'on suppose être vrai parce que notre programme est censé s'être assuré que c'est vrai. Dans le cas où c'est faux c'est une grave erreur interne et il n'y a rien à tenter, tout est fini.

C'est tout à fait vrai.

Les assert n'ont rien à voir avec les tests unitaires, et mettre un assert ne dispense pas de créer des tests unitaires.

Je n'ai jamais écrit que les asserts remplaçaient les tests unitaires...
J'ai dit qu'ils étaient aussi utiles qu'eux.

Je suis d'accord (cent fois d'accord) avec le problème de fond que pose un catch(Exception e) qui ne rime à rien puisqu'il ne s'attaque à rien de précis (on ne sait pas ce que l'on intercepte et donc, on sait peu quoi faire de l'incident mentionné). En revanche, écrire un catch(Throwable t) me semble très dommageable. J'ai connu pas mal de programmes qui ont fait un foin incroyable en prenant des OutOfMemoryError et ne s'arrêtant pourtant pas, et continuaient à faire des âneries alors qu'ils n'étaient plus en état d'agir. Et cela, du fait de ces catch(Throwable t) intempestifs.

Selon moi :
il est légitime qu'un throw d'une Error arrête le traitement. Et un catch(Throwable t) dans un programme visant à l'empêcher (ou se sentant capable de faire des choses intelligentes avant de le quitter) me paraît toujours dangereux.

Mais si par ailleurs, je suis heureux que lorsqu'une une Error est levée les programmes s'interrompent brutalement (c'est ce que je veux parce que c'est ce qu'il faut : l'assert doit arrêter le programme), en revanche, j'ai remarqué que les serveurs d'applications l'encaissaient mal, et que si mon EJB arrêtait son action sous le joug d'une Error, il provoquait occasionnellement par effet de bord l'arrêt ou l'instabilité du serveur d'application sur lequel il tournait (parce que les gestionnaires d'exceptions de ce serveur d'applications ne l'encaissent pas bien), et c'est pour cette raison que j'ai pris l’initiative d'abandonner les asserts au profit du Validate.

C'est ce que j'ai voulu dire dans mon message initial.

EDIT : @AdiGuba : Merci pour Objects.requireNonNull. Je n'avais pas vu cette nouvelle méthode.

[professeur shadoko]

moui ... et alors pourquoi ne pas créer une méthode générale qui fasse qqch dans ce style

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
 
public static boolean useExceptionsForAssert = Boolean.getBoolean("useExceptionsForAssert") ;
public static void check(boolean test, String message) {
 if(! test) {
    if(useExceptionforAssert)
     throw new SomeRuntimeException(message);
    // ici déclencher soi-même l'Error
 }
 return true ;
}

et ensuite dans le code appelant:

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
 
  assert Checks.check(x>0, "x positif s.v.p dans méthode smurf!")

on peut faire plus ou moins sophistiqué (ici c'est pour l'exemple)

[tchize_]

Si c'est pour faire des choses pareilles (validation de paramètres de méthodes avec exceptions, un peu partout dans le code), autant utiliser des api dédiées à ça, comme le JSR-303

[professeur shadoko]

Si c'est pour faire des choses pareilles (validation de paramètres de méthodes avec exceptions, un peu partout dans le code), autant utiliser des api dédiées à ça, comme le JSR-303

dans un contexte J2SE pas trop "Beané" j'aimerai bien avoir des controles de compile time sur des annotations de type Nullable, mais après je ne vois pas trop comment implanter des contraintes annotées qui soient bien bordées.
Mais c'est un sujet intéressant sur lequel je suis preneur de pointeurs.