Gestion des erreurs

Le
Jack
Bonjour,

j'aimerais partager mon expérience sur la gestion des erreurs. Mon boss
n'a jamais voulu entendre parler de assert, il est saoulé par les tests
unitaires (junit), et ne parlons surtout pas de checkstyle ou FindBugs.
Donc il a "développé" un mode de prévention d'erreur assez intéressant
finalement: il test tout, tout le temps. Avec lui, pas question d'avoir
une contrainte dans un objet du style tel attribut ne peut jamais être
null, dans CHAQUE méthode de l'objet, il re-test si le champ est null.

Ca peut paraitre complètement con comme méthode développement, mais en
fait, vu qu'il ne met jamais de javadoc, c'est beaucoup plus dur de
casse un code qui marchait. Une méthode a souvent des contraintes sur
ses arguments et sa valeur de sortie, bah là on ne peut faire aucune
supposition d'aucune sorte, sauf que ça va pas planter.

En gros, le but n'est plus de respecter les specs (car les specs sont
malheureusement finies APRES le code dans ma boîte), mais plutot
"que-ça-plante-pas" du genre:

private JTable getTabledansOnglet(int onglet){
java.awt.Component c = getComponent(onglet);
if ((c!=null) && (c instanceof javax.swing.JScrollPane)){
c = ((javax.swing.JScrollPane) c).getViewport();
if (c!=null){
c = ((javax.swing.JViewport)c) .getView();
if (c instanceof JTable){
return (JTable) c;
}
}
}

return null;

}

Cette méthode se trouve 20 lignes en dessous du code d'ajout d'un
onglet qui fait un truc du genre new JScrollPane(table). Mais quand
même il re-test à chaque niveau que la structure Swing est bien
respectée.

Encore pire, j'ai un collègue qui code en mode "me fait pas chier avec
des détails" et qui vérifie que Jtable.getSelectedRows() ne retourne
pas null alors que la javadoc dit que la méthode renvoit un tableau
vide mais pas null.

Est-ce que d'autres sont dans le même cas ? Avez vous trouvé des
arguments pour obligez ces messieurs qui code pour eux même à mesurer
l'importance de pas faire comme ils font, parce que je sent que je vais
finir par faire comme eux à force
Vidéos High-Tech et Jeu Vidéo
Téléchargements
Vos réponses
Gagnez chaque mois un abonnement Premium avec GNT : Inscrivez-vous !
Trier par : date / pertinence
Sylvain
Le #367634
Jack wrote on 28/01/2008 20:59:

Est-ce que d'autres sont dans le même cas ?


oui.

Avez vous trouvé des arguments pour obligez ces messieurs
qui code pour eux même


non pour eux-même, pour le code !
"eux" n'acceptent aucune évidence ou certitude qui finira par être
contredite.
le code sera toujours auto-protégé quelque que soit le amanagement
(refactoring) futur.

parce que je sent que je vais
finir par faire comme eux à force...


bienvenue!

Sylvain.

Aris
Le #367944
Bonjour,

j'aimerais partager mon expérience sur la gestion des erreurs. Mon boss
n'a jamais voulu entendre parler de assert, il est saoulé par les tests
unitaires (junit), et ne parlons surtout pas de checkstyle ou FindBugs.
Donc il a "développé" un mode de prévention d'erreur assez intéressant
finalement: il test tout, tout le temps. Avec lui, pas question d'avoir
une contrainte dans un objet du style tel attribut ne peut jamais être
null, dans CHAQUE méthode de l'objet, il re-test si le champ est null.

private JTable getTabledansOnglet(int onglet){
java.awt.Component c = getComponent(onglet);
if ((c!=null) && (c instanceof javax.swing.JScrollPane)){
c = ((javax.swing.JScrollPane) c).getViewport();
if (c!=null){
c = ((javax.swing.JViewport)c) .getView();
if (c instanceof JTable){
return (JTable) c;
}
}
}

return null;

}
Quelle horreur. En effet ce code ne plante pas, mais si une des valeurs

est nulle, il ne fonctionne pas comme prévu et au lieu de donner une
stack trace interessante pour pouvoir trouver la source du probleme, il
contourne le probleme en ne faisant rien.
Avec du code comme ça tu peux passer des heures à trouver la cause d'un
probleme (tel champ est à null) avec des symptomes du genre "tel phrase
ne s'écrit pas dans le rapport de 2000 pages produit par le systeme".
Système totalement ridicule.
Un code doit etre testé avec des junit. Les préconditions et
postconditions peuvent etre évaluées avec un assert mais ce n'est pas
une condition nécessaire (c'est aux unités de tests de faire ça).
En règle générale, les exceptions ne servent pas à rapporter des bugs,
mais uniquement des cas d'erreur non prévisibles à l'avance (erreur de
connection, de parsing, d'écriture, ... et pas "l'utilisateur a pas
coché textbox machin" ou "ici on devrait obtenir un résultat plus grand
que 0 mais si on a pas on envoie une exception machin recue 3 appels
plus haut pour traffiquer le résultat"

Cette méthode se trouve 20 lignes en dessous du code d'ajout d'un onglet
qui fait un truc du genre new JScrollPane(table). Mais quand même il
re-test à chaque niveau que la structure Swing est bien respectée.

inutile donc allourdis le code

Encore pire, j'ai un collègue qui code en mode "me fait pas chier avec
des détails" et qui vérifie que Jtable.getSelectedRows() ne retourne pas
null alors que la javadoc dit que la méthode renvoit un tableau vide
mais pas null.

Est-ce que d'autres sont dans le même cas ? Avez vous trouvé des
arguments pour obligez ces messieurs qui code pour eux même à mesurer
l'importance de pas faire comme ils font, parce que je sent que je vais
finir par faire comme eux à force...
prendre le pas et faire des unités de test. Si ton boss se plaint que

pendant que tu fais des tests tu ne codes pas et donc tu es moins
productif, montre quelques papiers sur extreme programming qui donnent
tous des preuves qu'un programmeur est plus efficace lorsqu'il investit
50% de son temps à écrire des tests.

et surtout montre lui que son code est juste crashsafe mais n'aide
absolument pas à débusquer les bugs




Publicité
Poster une réponse
Anonyme