Discussion :

[requinham]

Bonjour à tous,

Je voudrai demander ceux qui ont travaillés sur de gros projets C avec, éventuellement, plusieurs modules sur la meilleur façon de gestion de retour des fonctions.

Dans une phase avancée de développement de gros projets, on se retrouve avec des IHM se basant sur plusieurs couches allant jusqu'aux APIs d'interfaçage avec le matériel.
La gestion des retour des multiples fonctions s'avère une tâche complexe surtout que si on fait le choix de remonter les codes d'erreurs définis dans les couches sous jacentes pour afficher le problème source exact à l'utilisateur (absence de driver, dev qui répond pas, buffer tx de la carte est saturé, etc), et qu'on s’aperçoit par la suite que nous remontons à l'IHM des centaines de code d'erreur recueilli par ici et par là en remontant à travers les différents modules (erreurs d'IO, erreurs de mémoire, erreurs de nos algo, erreurs de BD, etc.).

Une deuxième méthode, plus facile, consiste à remonter deux état (succès ou échec) et à logger les problèmes. dans ce cas l'IHM ne pourra afficher avec fidélité les sources des problèmes mais se limitera à indiquer la dernière couche qui a retourner un problème.

Par rapport à vos expériences existe t il d'autres méthodologie efficace pour ces situations, existe t il des livres qui parlent de ça ?

Vos participations sont les bienvenues.

[Neckara]

Certains logiciel ne montrent pas la nature du problème et n'affichent qu'un code d'erreur dont la signification est souvent inconnue pour l'utilisateur.

Sinon, je pense qu'il faut distinguer 4 types d'erreurs :

- Les erreurs qui gênent le bon fonctionnement du programme, dans ce cas là on affiche un message d'erreur ;

- Les erreurs qui ne gênent pas le bon fonctionnement du programme, dans ce cas là, inutile d'afficher l'information auprès de l'utilisateur on va juste logger ;

- Les erreurs qui découlent d'autres erreurs, théoriquement la gestion des codes de retours des fonctions devrait empêcher les erreurs en cascade.
Il est inutile de les afficher ou de les logger puisqu'on sait que l'erreur A va entraîner les erreurs B, C, D, ...
Si jamais l'une des erreurs gêne le bon fonctionnement du programme, c'est l'erreur d'origine qui sera considérée comme une erreur de la première catégorie ;

- Les erreurs dont on se moque éperdument ou pour lesquelles il existe une alternative qui 'rattrape' l'erreur, il est alors inutile de logger ou d'afficher l'erreur.


Ainsi dès qu'un utilisateur a un problème, vous pouvez mettre soit en place un système "d'envois de rapport de bug" en envoyant automatiquement le fichier de log et un formulaire remplis par l'utilisateur.
Soit demander à l'utilisateur de mettre le fichier de log en pièce jointe et d'envoyer la description du problème via E-mail.


Mais avec ces fichiers de log, vous ne pourrez voir uniquement les erreurs que vous avez déjà identifié.
C'est pour cela qu'on peut aussi logger le démarrage de l'application et l'entrée dans certaines fonctions afin de connaître un peu mieux les circonstances de l'erreur.

[requinham]

Le problème ne sont pas des problèmes de crash et de post traitement. L'objectif est de mentionner avec fidélité les problèmes rencontrés à l'utilisateur afin qu'il puisse comprendre et si possible intervenir.

-Les erreurs qui découlent d'autres erreurs, théoriquement la gestion des codes de retours des fonctions devrait empêcher les erreurs en cascade.
Il est inutile de les afficher ou de les logger puisqu'on sait que l'erreur A va entraîner les erreurs B, C, D, ...

Si j'ai bien compris, je dirai que ceci n'est pas toujours vrai, même si l'erreur A engendre la B, C et la D il faudra mentionner les autres erreurs engendrés aussi, prenons l'exemple simple d'une erreur d'insertion dans une liste chaînée. remonter ceci à l'utilisateur (en lui mentionnant problème de ressource) n'est pas très explicite surtout dans un contexte multithreadé dans lequel plusieurs threads partage cette liste mais chacun pour une fonctionnalité bien spécifique et que c'est le thread x qui a eu ce problème !

Étudions un cas spécifique

[Neckara]

Le problème ne sont pas des problèmes de crash et de post traitement. L'objectif est de mentionner avec fidélité les problèmes rencontrés à l'utilisateur afin qu'il puisse comprendre et si possible intervenir.

Est-ce vraiment le rôle de l'utilisateur ?
Si l'erreur est une erreur du style : "accès internet non trouvé", "fichier de configuration machin non trouvé" je comprends.
Mais pour les autres erreurs, c'est plus au programmeurs de comprendre, l'utilisateur a juste besoin de savoir qu'il y a eu une erreur puis de savoir comment avertir l'équipe.
L'utilisateur n'a pas à plonger dans le code-source pour corriger lui-même l'erreur.

Si j'ai bien compris, je dirai que ceci n'est pas toujours vrai, même si l'erreur A engendre la B, C et la D il faudra mentionner les autres erreurs engendrés aussi, prenons l'exemple simple d'une erreur d'insertion dans une liste chaînée. remonter ceci à l'utilisateur (en lui mentionnant problème de ressource) n'est pas très explicite surtout dans un contexte multithreadé dans lequel plusieurs threads partage cette liste mais chacun pour une fonctionnalité bien spécifique et que c'est le thread x qui a eu ce problème !

Mais qui nous dit que l'erreur ne vient pas du thread Y qui aurait laissé la liste dans un mauvais état provocant ainsi l'apparition du message d'erreur dans le thread X?
Puis que les autres messages d'erreurs proviennent ensuite du thread Y ?


Ce qu'il y a après, on sait que ça va planter de toute façon.

Tu peux aussi créer une pile où tu empilera le nom ainsi que les paramètres des fonctions au fur et à mesure des appels et que tu dépilera au fur et à mesure des retours.

Lorsque survient l'erreur, tu pourras ainsi reproduire l'erreur et comprendre ce qu'il c'est passé assez facilement.

[requinham]

La bonne stratégie d'après vos remarques est de remonter juste l'erreur ou l'info mentionnant le type de problème (dans sa généralité) et de loguer ou bien empiler dans des structure interne la pile des retours afin de les analyser ultérieurement et non pas remonter tout et afficher à l'utilisateur la source exact en lui indiquant un code d'erreur à retourner au support technique par exemple ?

Ceci ne dépend il pas de la nature de l'application, si c'est pour des fins industriel avec pilotage de banc complexe (dans lequel l'utilisateur est un technicien et qui a besoin des réponses des interfaces qui ont généré le problème) ou bien une simple application de traitement de texte ?