Discussions au sujet de NI LabVIEW
arret en cas d'erreur: la fenetre ne disparait pas
Salut Ouadji, oui, je pense même que nos réponses se complètent. bonne journée à tous !
Ceci dit ...
il m'arrive également d'utiliser une fonction "clear error" ... quand certaines choses doivent "ab-so-lu-ment" être exécutées même s'il y a erreur.
Mais je me suis fait ma propre fonction "clear error" (sur le fond ...la même que la fonction native)
mais avec un autre design ... j'ai en horreur le "look" de la fonction "clear error" native de LV (qu'elle est moche 
)
Michael.C : " je stocke les erreurs dans un fichier log afin de garder une trace de ce qui se passe dans mes programmes "
Je comprends ... sans comprendre.
Si ton flux d'erreur, et sa gestion globale, est "bien cablé", quand il y a une erreur ... tu sais exactement "quoi" et "ou".
Je suppose alors que tu corriges ton erreur de code (tu debugges éventuellement, et tu "rectifies" le soucis)
Je veux dire pas là que l'élimination des erreurs se fait en temps réel pendant le développement.
Que conserves-tu en réalité dans ce "fichier log" ... et surtout pour en faire quoi ensuite ?
tu as raison michael
Ouadji, il faut imaginer 4 types d’erreurs (au moins).
- erreur code brisé, impossible de compiler. Pas d'exe.
-
Une erreur de programmation qui est permanente, et qui sera trouvée par le test unitaire du vi, en mode de développement.
-
Une erreur de programmation qui est causée par la combinaison de plusieurs états. Le logiciel fonctionne, mais parfois il y a une erreur. Le logiciel sera chez l’utilisateur final. Comment se dernier va-t-il remonter le dysfonctionnement à l’équipe de développement ?
-
Une erreur d’utilisation, par exemple « je veux imprimer » mais "pas d’imprimante connectée ». Je contacte le support. Quelles informations a donner?
Le fichier log d’erreur doit permettre à l’équipe de développement de répondre à depuis les erreur 3 et 4 à :
-
quand
-
quelle fonction, quel vi
-
pourquoi
-
Warning ou erreur
-
trouver le scénario du bug
L’idée est d’avoir un fichier horodaté, avec le code de l’erreur et la source avec la chaîne d’appel (call chain).
Il est même possible d’ajouter la balise « append » dans l’erreur standard de LabVIEW pour ajouter un message personnalisé.
Merci Luc d'avoir répondu pour moi 
En effet, j'évoquais la gestion des erreurs dans le contexte d'utilisation finale.
Mon application est utilisé dans des contextes variables (interface multiple, configuration variable (portable, pc indus), divers OS, et plusieurs interfaces (RS485, profibus, modbus,....), il est donc très utile pour moi de conserver une trace des erreurs majeurs ou mineurs qui peuvent se produire de manière ponctuelle.
En plus d'un horodatage, je vais venir aussi stocké des indications propres au poste hébergant l'exécutable (mémoire dispo, nom, OS, référence utilisateur,...).
L'idée est de pouvoir identifier un problème à distance, en obtenant le plus facilement, possible un maximum d'informations de la part de l'utilisateur.
Cdt,
Michael
ok, compris ...
Vu que je suis le développeur et le client en même temps (cela explique)
Je parlais des erreurs 1 et 2.
Je suis parfaitement d'accord pour le fichier log en ce qui concerne les erreurs de type 3.
Quoi que ... "Le logiciel fonctionne, mais parfois il y a une erreur" ... me laisse un rien perplexe.
Les tests au niveau développement ont-ils été sufisants ? A-t-on testé toutes les configurations possibles ?
A l'évidence, non ... puisque "parfois" une erreur se produit.
Mais bon ... dans un soft de grande ampleur et complexe, aucun développeur n'est a l'abris d'un "bug caché".
Donc, ok, suis d'accord.
Quant aux errreurs de type 4, c'est moins "évident" .... il me semble qu'elles devraient être traitée par le soft lui-même.
(messages d'informations et explicatifs donné à l'utilisateur par le programme lui-même).
Ceci dit, l'exemple de l'imprimante est un exemple "simple" ...
je peux facilement comprendre que des "dysfonctionnements" plus complexes nécessitent d'avoir des "infos" à donner au service support.
En résumé
et cela correspond à ta conclusion ... pour les erreurs de types 3 et 4, ok pour le fichier log.
[edit]
Je viens de lire la réponse de Michael ...
en effet, cela fait appel à une sphère beaucoup "plus large" que celle à laquelle je pensais.
[/edit]
