assert : ca vous cause

Marsh Posté le 02-06-2003 à 15:12:11

Je viens de decouvrir ca dans un article sur developpezz.com : source

Je savais que le concept existait, mais je pensais pas que ca existait.
J'aimerai donc savoir si je suis a la masse, ou c'est normal, et puis ca fait un sondage, c'est marrant ...

A priori, ca me parait pas mal, ca permet de securiser le code, surtout quand on retouche/reutilise du code apres plusieurs semaines ...

---------------
get amaroK plugin

Reply

Marsh Posté le 02-06-2003 à 15:12:11

Reply

Marsh Posté le 02-06-2003 à 15:15:30

C'est une nouveauté du JDK 1.4

Et ça roulaize, perso, je fait mes precond/postcond/invariants avec ça :love:

---------------
brisez les rêves des gens, il en restera toujours quelque chose... -- laissez moi troller sur discu !

Reply

Marsh Posté le 02-06-2003 à 15:17:11

kadreg a écrit :

Et ça roulaize, perso, je fait mes precond/postcond/invariants avec ça :love:

moi je m'en sers pas, les composants deviendraient beaucoup trop prévisibles... Où est la poésie dans tout ca, hein ?

Reply

Marsh Posté le 02-06-2003 à 15:26:25

Moi je n'arrive pas à en saisir l'intéret ! :sweat:
Quel effet ça fait à l'utilisation si la condition d'un assert n'est pas "vraie" ?
Pourquoi utliser de assert plutôt que des exceptions ?

Reply

Marsh Posté le 02-06-2003 à 15:28:55

c'est quoi assert ?

Reply

Marsh Posté le 02-06-2003 à 15:29:41

backdafuckup a écrit :

c'est quoi assert ?

Lien dans le 1er post... :ange:

Reply

Marsh Posté le 02-06-2003 à 15:31:10

El_gringo a écrit :

Moi je n'arrive pas à en saisir l'intéret ! :sweat:
Quel effet ça fait à l'utilisation si la condition d'un assert n'est pas "vraie" ?
Pourquoi utliser de assert plutôt que des exceptions ?

Si c'est comme en C ca te sort un joli "assertion failed", avec le code correspondant!
Par contre je vois pas pkoi ne pas utiliser des exceptions, en effet... :??:

Reply

Marsh Posté le 02-06-2003 à 15:38:57

skeye a écrit :

Si c'est comme en C ca te sort un joli "assertion failed", avec le code correspondant!
Par contre je vois pas pkoi ne pas utiliser des exceptions, en effet... :??:

La réponse est sur le site de sun.

Quand tu élimines l'assert, tu vires tout le code de l'exécution, alors qu'avec une exception, tu dois faire le test à chaque fois.

Imagine une précondition sur le type des éléments d'une collection, la complexité a légèrement tendance à baisser quand tu vires l'assert.

À noter que toute la programmation par contrats est décrite dans le Meyer (Conception et programmation orientées object) que vous auriez du tous lire avant de poster.

Reply

Marsh Posté le 02-06-2003 à 15:39:57

nraynaud a écrit :

À noter que toute la programmation par contrats est décrite dans le Meyer (Conception et programmation orientées object) que vous auriez du tous lire avant de poster.

Je l'ai lu

---------------
brisez les rêves des gens, il en restera toujours quelque chose... -- laissez moi troller sur discu !

Reply

Marsh Posté le 02-06-2003 à 15:43:30

nraynaud a écrit :

À noter que toute la programmation par contrats est décrite dans le Meyer (Conception et programmation orientées object) que vous auriez du tous lire avant de poster.

:ange:

kestu veux [:spamafote] on est des artisans, on a du mal avec les bouquins

---------------
get amaroK plugin

Reply

Marsh Posté le 02-06-2003 à 15:43:30

Reply

Marsh Posté le 02-06-2003 à 15:43:31

nraynaud a écrit :

La réponse est sur le site de sun.

Quand tu élimines l'assert, tu vires tout le code de l'exécution, alors qu'avec une exception, tu dois faire le test à chaque fois.

Imagine une précondition sur le type des éléments d'une collection, la complexité a légèrement tendance à baisser quand tu vires l'assert.

À noter que toute la programmation par contrats est décrite dans le Meyer (Conception et programmation orientées object) que vous auriez du tous lire avant de poster.

Si tout le monde attendait de connaitre sur le bout des doigts un sujet avant de poster, l'intérêt du forum ne serait plus du tout le même.
J'ai pas compris ce que t'as expliqué sur l'intéret d'un assertion par rapport à une exception.

Reply

Marsh Posté le 02-06-2003 à 15:47:56

El_gringo a écrit :

J'ai pas compris ce que t'as expliqué sur l'intéret d'un assertion par rapport à une exception.

Désactiver du code de contrôle quand tu es en prod.

Reply

Marsh Posté le 02-06-2003 à 15:52:57

nraynaud a écrit :

Désactiver du code de contrôle quand tu es en prod.

Ha, ok. En prod, le JVM doit être lancée de manière à ne pas utiliser assertions.
D'un autre côté, c'est bien pratique d'utiliser des exception, que l'on logue, même en prod. ça permet de localiser les bugs facilement!

EDIT : et puis désactiver ces contrôles en prod, je n'en voit pas l'intéret, puisque, à ce que j'ai compris, on ne doit mettre en assert que ce qui est essentiel au fonctionnement du programme. Si on désactive ces contrôles, qu'est ce qui se passe s'la condition n'est pas respectée !? il faut doubler chaque assert d'une exception alors !?

Message édité par El_gringo le 02-06-2003 à 15:54:51

Reply

Marsh Posté le 02-06-2003 à 16:07:01

El_gringo a écrit :

EDIT : et puis désactiver ces contrôles en prod, je n'en voit pas l'intéret, puisque, à ce que j'ai compris, on ne doit mettre en assert que ce qui est essentiel au fonctionnement du programme. Si on désactive ces contrôles, qu'est ce qui se passe s'la condition n'est pas respectée !? il faut doubler chaque assert d'une exception alors !?

Tout est écrit sur le site de sun et dans le Meyer (et surement dans des dizaines d'autres bouquins), y compris les pièges à con et les cas d'école. Je te rassures, lire un bouquin ne fera pas de toi un expert mais contribuera à t'améliorer.

http://java.sun.com/j2se/1.4.1/doc [...] ssert.html

plus spécifiquement : si c'est désactivé c'est qu'il va rien se passer même s'il y a un bug, tu vas aller au tas plus tard.
Non, si tu veux que ça se lève en proc aussi, tu mets une exception, pas une assertion.

Message édité par nraynaud le 02-06-2003 à 16:07:58

Reply

Marsh Posté le 02-06-2003 à 16:14:11

La solution est dans le livre de Meyer [:totozzz] [:taichetoz] [:drasche] .

---------------
Le site de ma maman

Reply

Marsh Posté le 02-06-2003 à 16:17:17

nraynaud a écrit :

Tout est écrit sur le site de sun et dans le Meyer (et surement dans des dizaines d'autres bouquins), y compris les pièges à con et les cas d'école. Je te rassures, lire un bouquin ne fera pas de toi un expert mais contribuera à t'améliorer.

http://java.sun.com/j2se/1.4.1/doc [...] ssert.html

plus spécifiquement : si c'est désactivé c'est qu'il va rien se passer même s'il y a un bug, tu vas aller au tas plus tard.
Non, si tu veux que ça se lève en proc aussi, tu mets une exception, pas une assertion.

ça va, je m'inquiétais pas trop...

Mais par exemple, dans ce code :

Code :

/**
* Vérification de l'égalité de deux intervalles.<p>
* Vérifie que les deux intervalles soient bien équivalents en comparant simplement
* la date de début et la date de fin.
* @return vrai, si les deux intervalles sont équivalents.
*/
public boolean equals(java.lang.Object obj) {
if (null == obj) { // rien à comparer
return false;
}
if ( ! (obj instanceof DateIntervalle)) { // pas le bon type d'objet
return false;
}
DateIntervalle intervalle = (DateIntervalle) obj;
assert null != getBeginAt();
assert null != getEndAt();
return getBeginAt().equals(intervalle.getBeginAt()) && getEndAt().equals(intervalle.getEndAt());
}

Si les assertions sont ignorées par le JVM courante, l'utilisateur peut va se prendre un NullPointerException
Je ne vois pas ce qu'apporte l'assertion au développeur...

Reply

Marsh Posté le 02-06-2003 à 17:03:28

El_gringo a écrit :

Mais par exemple, dans ce code :

Code :

assert null != getBeginAt();
assert null != getEndAt();
return getBeginAt().equals(intervalle.getBeginAt()) && getEndAt().equals(intervalle.getEndAt());

Je ne vois pas ce qu'apporte l'assertion au développeur...

moi non plus, si son invariant de classe est en vrac c'est sûrement pas là qu'il faut le détecter, c'est beaucoup trop tard.
T'as l'auteur du code sous la main ? C'est un mec suceptible d'avoir une bonne raison de faire ça ?

Par contre, dans les cas où ça risque de pêter 3 heures après le bug c'est utile de mettre une assertion car chercher pourquoi une valeur erronée est là où elle se trouve peut être assez long.

PS : j'ai eu une réunion au milieu du post, je suis pas sur que ce soit très clair.

Reply

Marsh Posté le 02-06-2003 à 17:27:38

nraynaud a écrit :

moi non plus, si son invariant de classe est en vrac c'est sûrement pas là qu'il faut le détecter, c'est beaucoup trop tard.
T'as l'auteur du code sous la main ? C'est un mec suceptible d'avoir une bonne raison de faire ça ?

Par contre, dans les cas où ça risque de pêter 3 heures après le bug c'est utile de mettre une assertion car chercher pourquoi une valeur erronée est là où elle se trouve peut être assez long.

PS : j'ai eu une réunion au milieu du post, je suis pas sur que ce soit très clair.

L'auteur est celui du lien du 1er post !

Reply

Marsh Posté le 02-06-2003 à 17:52:16

El_gringo a écrit :

L'auteur est celui du lien du 1er post !

Je viens de lire c'est nul.
Le lien ver jcontractor est pas mal, je savais pas qu'il était aussi bien ce truc. Par contre je trouve ça lourd d'écrire 2 méthodes autour de chaque méthode.

Reply

Marsh Posté le 02-06-2003 à 18:04:25

Je viens de capter la blague :

Citation :

Sujet : assert : ca vous cause

Si ça cause, c'est pas bon signe ...

Reply

Marsh Posté le 02-06-2003 à 18:23:20

nraynaud a écrit :

Je viens de capter la blague :

Citation :

Sujet : assert : ca vous cause

Si ça cause, c'est pas bon signe ...

:??:

En tout cas, merci pour tes quelques explications ... mais j'ai pas encore tout compris ... va falloir que je lise le bouquin de meyer ...

---------------
get amaroK plugin

Reply

Marsh Posté le

Reply

assert : ca vous cause

Sujets relatifs:

Leave a Replay