Discussions au sujet de NI LabVIEW
Curiosité : La gestion d'erreur
Résolu !
Bonjour à tous !
Petite question de curiosité, que se passe t'il si je ne gère pas les erreurs ? C'est a dire que je laisse vide entrée/sortie d'erreur, que mes sousVI ne possède pas d'entrée et sortie d'erreur ?
Parce qu'actuellement quand je lance mon programme, si il y a un soucis de cablage j'ai l'erreur, et si il y a un soucis sur un VI-express comme DAQassist ... et bien labview me le montre.
Pourquoi cette question ?
Et bien par exemple, et c'est plus pour un soucis de présentation, mais j'ai beaucoup de VI de ce style, cela ne convient pas à tout le monde, mais pour moi c'est clair, et tout mettre en ligne avec une gestion d'erreur (parce que quitte à la faire, autant que ce soit propre) et bien je trouve ça moins compréhensible !
(alors après oui, ici je peux peut etre creer un tableau et faire une boucle for, j'y pense en écrivant la, vous pensez que ce serait mieux ? Au moins ça diminuerait le nombre de VI comparaison)
Parce que mon programme final n'aura pas d'executable (la boite ou j'effectue mon stage ne veux pas dépenser dans le module) donc est-ce necessaire ?
Merci
Erwan
J'aime beaucoup l'explication de Maxime_L , à la fois succincte et complète.
et notamment cette phrase : " ... ce que votre code doit faire ou non lorsqu'il rencontre une erreur ". (c'est une grande vérité !)
Pour l'utilisateur, de façon "externe", un programme ne doit jamais "être en défaut".
Du point de vue de l'utilisateur, une boîte de dialogue avec un message d'erreur ... est une horreur absolue.
Un code doit être robuste, fluide et doit pouvoir s'adapter à tous les cas de figure possibles.
Si maintenant, de façon interne il en génère une ... il doit pouvoir adapter son algorithme de manière à "répondre" à cette erreur.
Une erreur traitée, c'est un programme bien fait ... une erreur non traitée, c'est un bug.
Maintenant, pour pouvoir la traiter ... le minimum est de l'intercepter ... d'où le flux d'erreur.
Je me demande même si la qualité d'un programme ne pourrait pas être définie (entre autres) par la qualité de sa gestions des erreurs ?
(juste mon avis)
Merci à vous deux pour vos réponses ! J'ai saisi le truc !
J'ai du pain sur la planche alors ..... parce que la ... 
@ Erwan : " J'ai du pain sur la planche alors "
L'essentiel n'est pas de faire une gestion de l'erreur de façon parfaite et absolue. (tous les codes ne sont pas destinés à la NASA)
Quand un code devient complexe (voir très complexe) ... qui peut se targuer d'avoir prévu TOUS les cas d'errreurs possibles ?
C'est là le fondement même de la problématique de la fiabilité d'un code. (vaste domaine)
Une gestion de l'erreur peut-être plus ou moins simple ... ou plus ou moins complexe ... (suivant le degré de robustesse que l'on désire)
Mais alors où est l'essentiel ?
Que la gestion de l'erreur soit "ultra simple" ou "très élaborée", l'essentiel est qu'elle existe ... et de ne pas complètement l'éliminer.
L'essentiel est de bien comprendre à quoi elle sert, et surtout ce à quoi on s'expose si on en tient pas compte.
Après cela ... en toute connaissance de cause, on adapte cette gestion de l'erreur au contexte ... complexité du code, degré de robustesse souhaité, etc.
