Discussion :

[Menuki]

Bonjour à tous,

Je ne sais pas si c'est le bon forum pour poser cette question mais voici :

Nous avons pris livraison d'une nouvelle librairie que notre revendeur nous présente comme le must en la matière (pas gratuite du tout, je précise en passant).

PB: Premier test = plantage.

Alors, histoire de m'assurer que je ne mets pas mes erreurs sur le dos des autres (j'ai horreur de passer pour un con), j'isole le code incriminé.
J'obtiens ces ridicules petites lignes de code :

Code :

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

1
2
3
4
5
6
7
8
9
#include <PvConfigurationReader.h>
int main(void)
{
  PvConfigurationReader reader;
  reader.GetDeviceCount(); // <- produit un ACCESS VIOLATION

  return 0;
}

On ne peut pas faire plus court...
Fan de "La petite maison dans la prairie", je me dis que j'ai là l'occasion de faire une bonne action : j'envoie un rapport au support technique du revendeur pour qu'il remonte le problème aux concepteurs.

Réponse du directeur technique himself (je résume) :

C'est normal que ça plante. Il faut appeler la méthode Load() avant et vérifier que la lecture du fichier s'est bien passée.

Auquel, je réponds :

Je veux bien. J'ai fait les choses dans le désordre mais si ça plante c'est qu'il y a un bug.

Réponse :

Non, non! Ce n'est pas un bug. Il suffit de faire les choses dans le bon ordre et ça ne plantera pas.

Je vous passe les heures au téléphone pour essayer de comprendre pourquoi ce monsieur ne veut pas remonter le problème aux concepteurs.
La dernière qu'il m'a sorti, c'est que

ce n'est pas un problème de librairie mais un problème de C++.

Là, il m'a scotché . Dès que j'ai l'explication de ce que cela veut dire, je vous la donne...

Bref, on tourne en rond.

Mon avis : C'est inadmissible qu'un appel à une fonction (ou méthode) plante. C'est de la responsabilité du développeur de la fonction (ou de la classe) de s'assurer au minimum qu'il dispose des resources nécessaires à la bonne execution de la requête et sinon de renvoyer une erreur.
Certains diront qu'on ne peut pas tout vérifier mais avant d'accéder au contenu d'un buffer, on peut au moins s'assurer qu'il est initialisé proprement. Non?

Alors histoire d'avoir les idées claires, je demande l'avis des professionnels qui trainent sur le forum.
Bien que ce message soit écrit sur un ton un peu léger, ce sujet est extrémement sérieux. Je demande donc aux non professionnels ou ceux qui n'ont pas d'avis de ne pas intervenir.
Je demanderai aussi que les intervenants argumentent leur propos.

Cela me permettra peut-être de savoir si mes exigences en termes de robustesses et de responsabilités sont légitimes.
Et au final, peut-être arriverons-nous à trouver, ensemble, une définition universelle du bug (mais là, je rêve sûrement )

[Garulfo]

There are two ways of constructing a software design; one way is to make it so simple that there are obviously no deficiencies, and the other way is to make it so complicated that there are no obvious deficiencies. The first method is far more difficult.

Sir Tony Hoare l'a dit on ne pourra jamais échapper aux « bugs ». Il a aussi dit que les pointeurs étaient la misère du monde. Sur ces deux points, je suis d'accord avec lui.

Le problème est comme tu l'as sous-entendu la définition de bugs. On peut dire que ton histoire montre un « bug », mais on pourrait aussi dire que ça n'en est pas un. Le terme « bug » revêt trois sens différents : l'erreur (error) humaine, la déficience (deficiencies) du programme en un de ses points et qui est due à l'erreur humaine, la faute (failure) commise lors de l'exécution par cette déficience.

[Tommy31]

Ce qui est grave c'est qu'il n'y ait pas une jetée d'exception qui précise la nature du problème. Une simple assertion en précondition, le genre de truc qui ne coute rien et qui aide au développement.

Sinon, on ne peut pas réellement parler d'un bug si le domaine de définition, ou le contexte d'utilisation n'est pas respecté (à condition qu'il soit un minimum décrit).

[el_slapper]

Assez d'accord avec Tommy. Si le processus d'appel n'est pas bon(ce qui est la réponse de l'assistance, donc je suppose que c'est vrai), l'erreur renvoyée doit être "propre" et ne pas gameller l'application appelante. Ce qui n'est pas le cas.

[Menuki]

Tout d'abord merci pour vos réponses.

Je viens de lire un message du support technique qui me réexplique qu'on ne peut pas parler de bug.

Il argumente en disant que le compilateur n'initialise pas par défaut les variables membres (le fameux problème du C++ décrit dans mon premier message) et surtout :

Rien n'impose et surtout il n'est pas toujours possible, que le constructeur par defaut initialize la totalité des champs et membres de (des) objet(s) et si une API explicite d'initialisation est présente elle doit etre utilisée pour cela.

Peut-on vraiment parler de bug?
Garulfo l'a bien souligné, la définition du bug est bien vague et se présente sur plusieurs niveaux (ce que me dit aussi ce directeur technique, comme quoi...).

Alors pour éviter de pinailler sur des détails et des problèmes de sémantique, ne parlons plus de bug mais de politesse entre gens civilisés...
Posons le problème autrement :
Est-ce que ce sont des choses qui se font de reporter toutes les responsabilités sur l'utilisateur final?

Pour ma part, je réponds que non et d'après les réponses que j'ai vu, beaucoup pensent pareil.

Pour etayer ce que je dis, prenons un exemple de la vie courante :
Vous avez un lave-linge et si vous suivez à la lettre ce qui est décrit dans la notice, vous vous attendez à ce que votre linge ressorte propre et en bon état comme au premier jour
A présent, si je mets à laver le beau pull en pure laine vierge que j'ai offert à ma copine pour son anniversaire et que je le mets sur lavage à 90° au lieu de lavage à froid, il y a de forte chance pour que le pull ait pris la taille playmobil et, accessoirement, que je dorme dans la niche du chien pendant les 6 prochains mois .
Puis-je en tenir rigueur au constructeur?
Non, car je n'ai pas suivi la notice et donc, il ne peut pas me garantir le résultat.
Idem, si je ne mets pas de lessive.

Par contre, si, en oubliant la lessive ou en me trompant de programme, ça fait exploser la machine et tout l'appartement avec, j'ai quand même le droit d'aller voir le fabricant et de lui demander des explications.

C'est le minimum qu'on puisse demander à une machine à laver. A partir du moment, où je n'ai pas mis de la nitro dedans, j'attends qu'elle ne me pète pas à la figure.

Hé bien cette exigence, je l'ai aussi envers les librairies que j'utilise.
La nitro dans ce cas, ce serait un pointeur non-initialisé, un buffer désalloué...
Là, rien de tout ça.
Je crée un objet et je voudrais qu'il me donne une information (je précise qu'effectivement, je ne suis pas la notice).
Je pense qu'il y a d'autres moyens de m'envoyer paître que de me faire planter l'appli' et là, je rejoins el_slapper et Tommy...

[souviron34]

je suis d'accord avec toi...

A mon sens, en aucun cas une application ou une biblitothèque ne devrait provoquer un crash...

J'ai cependant l'impression que c'est quelque chose de très génralement répandu, en particulier avec le traitement des exceptions avec des langages comme C++...

Et je pense que cela vient de la notion de ces "exceptions" et de leur enseignement (ou non)..

Une discussion sur un autre forum :
...pourquoi-gens-utilisentils-exceptions-cpp/
était assez édifiante à ce sujet... (j'ai mis longtemps à la retrouver !!!)

Effectivement, faire un code propre qui ne plante jamais est plus long, fastidieux

Alors que faire une exception qui fait "exit" ou aucune (donc "crash") est nettement plus facile

Dans le cas contraire, il faut penser tous les effets de bords, avec un code sûr, et de plus la plupart du temps avec un style plus "code d'erreur" que "exception" (même si il en existe quelques unes pour mettre les flags à jour)..

Je pense que c'est une très grave lacune, mais que malheureusement ça m'a l'air très répandu (voir la discussion)...