Discussion :

[Spout]

Hello à tous!
J'ai un programme (IHM) qui en lance un autre en mode silencieux, c'est-à-dire qu'il en appelle explicitement l'exécutable via une fonction du type ShellExecute(). Cet autre programme n'a pas d'IHM et se ferme tout seul quand il a fini son traitement.
Ce que je voudrais, c'est que si jamais ce deuxième programme rencontre des erreurs au cours de son exécution, il en informe le premier.
Pour l'instant, j'ai envisagé d'écrire un fichier (type INI) qui sera lu par le premier programme au moment ou le deuxième s'arrêtera, mais je n'aime pas trop cette solution.
Ma question est donc simple: connaissez-vous d'autres moyens de signifier un tel retour d'exécution? Je voudrais pouvoir y mettre un ou plusieurs codes d'erreur avec du texte associé.
Merci d'avance.

[ram-0000]

Pour une gestion simple/minimale, tu peux récupérer le code de retour du programme appelé
code ret = 0 ==> OK
code ret = 1 ==> fichier non trouvé
...

Après, c'est à toi de définir tes conventions de code de retour
le programme appelé doit respecter cette convention
le programme appelant doit connaitre cette convention.

Par contre, tu ne pourras jamais retourner que des nombres. Si tu veux plus d'informations (des chaines de caractères par exemple), il va falloir passer par une autre technique (fichier de résultat intermédiaire, ...)

[koala01]

Salut,

La solution passe, tout simplement, par l'utilisation correcte du prototype de la fonction principale: int main() (ou int main(int argc, char* argv[])

En effet, main peut renvoyer deux (ou trois) valeurs différentes (en fonction du système d'exploitation):

• 0 si l'exécution s'est terminée correctement
• 1 si l'exécution s'est terminée sur une erreur
• 2 si l'exécution s'est terminée sur un avertissement (uniquement sous unixoïdes, et non disponible sous windows)

Grâce à cela, tu pourra utiliser le retour de la commande ShellExecute pour vérifier si elle s'est terminée correctement:

• Si la valeur est supérieure 32: la commande s'est bien déroulée
• Si la valeur est inférieure à 32, la commande a eu un problème

Tu peux même te baser sur les valeur prédéfinies pour déterminer ce qui ne s'est pas passé correctement (cf la doc de shellExecute) pour le cas où l'application appelée n'a pas respecté les restrictions du système d'exploitation

[Spout]

Merci pour vos réponses .

Sauf que j'avais oublié de vous préciser une chose très importante : je ne maîtrise pas la manière dont le deuxième programme est appelé .
Celui-ci est un outil que je développe et qui sera appelé par un séquenceur (premier programme) qui peut lancer d'autres exécutables. D'où ma déduction qu'il utilise une fonction du type ShellExecute(). Je suis en train de me renseigner pour vérifier quelle fonction est utilisée et si une analyse du code de retour est faite.

Mais La fonction ShellExecute(), si je ne me trompe pas, lance le fichier passé en paramètre et ressort aussitôt, non? Elle n'attend pas que le processus lancé se termine, si? Auquel cas cette solution ne m'irait pas du tout car je peux avoir des erreurs au cours de l'exécution de l'outil, même si celui-ci a bien été lancé.
Tout ce qui m'intéresse, c'est les différents codes et textes de retour liés à mon exécution et non ceux liés au lancement du processus. Ceux-là doivent être gérés par le séquenceur.

Je reviens alors à ma première question. Si l'on considère que je n'ai pas accès au code de retour de la fonction qui appelle l'exécutable de mon outil, comment faire savoir au séquenceur le(s) erreur(s) que l'outil a pu rencontrer?

Dites-moi si je suis pas assez clair

[koala01]

Si tu ne peux pas forcément avoir accès au retour de l'appel, et que tu as des informations potentiellement multiples à faire connaitre, le mieux est effectivement de passer par un système de "logging"...

N'oublie alors pas de "structurer" correctement les informations que tu met dans le fichier log, sous une forme proche - par exemple - de:

Code :

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

[AA/MM/DD hh:mm:ss] niveau, contexte, problème

ou

• AA représente les deux chiffres de l'année
• MM représente les deux chiffres du mois
• DD représente les deux chiffre du jour
• hh représente l'heure
• mm représente les minutes
• ss représente les secondes
• niveau représente le "niveau de récupérabilité" de l'erreur (0 = warning, 1 = erreur simple, 2 = erreur récupérable, 3 = erreur fatale...)
• contexte représente le contexte dans lequel l'erreur est apparue
• problème représente le problème tel qu'il s'est présenté

[Spout]

Ouais. Je crois que je vais pas trop avoir le choix...

Le retour d'erreur est destiné au séquenceur pour qu'il sache, après avoir lancé l'outil, si celui-ci a accompli correctement sa tâche ou pas. Disons que pour les utilisateurs du séquenceur, c'est plus facile de lire les erreurs dans un fichier que d'implémenter la gestion de retour d'erreurs spécifiques à mon outil alors que celui-ci est lancé par une commande qui est à la base générique à tout fichier exécutable.

Je me dis alors que le formatage tel que tu me proposes n'est pas forcément utile s'il n'est qu'à destination du séquenceur. Par exemple je ne pense pas que les dates soient nécessaires car ce fichier ne serait créé qu'à la demande explicite du séquenceur (lancement de l'outil) + éventuelles erreurs dans son exécution. Autant simplifier alors la lecture logicielle du fichier et éviter le superflu dans le déformatage de la ligne, non?
Mais j'ai bien noté que ce n'était qu'un exemple .

Autre question: qu'est-ce que tu entends par "contexte dans lequel l'erreur est apparue"?

[koala01]

Ouais. Je crois que je vais pas trop avoir le choix...

Le retour d'erreur est destiné au séquenceur pour qu'il sache, après avoir lancé l'outil, si celui-ci a accompli correctement sa tâche ou pas. Disons que pour les utilisateurs du séquenceur, c'est plus facile de lire les erreurs dans un fichier que d'implémenter la gestion de retour d'erreurs spécifiques à mon outil alors que celui-ci est lancé par une commande qui est à la base générique à tout fichier exécutable.

Je me dis alors que le formatage tel que tu me proposes n'est pas forcément utile s'il n'est qu'à destination du séquenceur. Par exemple je ne pense pas que les dates soient nécessaires car ce fichier ne serait créé qu'à la demande explicite du séquenceur (lancement de l'outil) + éventuelles erreurs dans son exécution. Autant simplifier alors la lecture logicielle du fichier et éviter le superflu dans le déformatage de la ligne, non?
Mais j'ai bien noté que ce n'était qu'un exemple .

A vrai dire, il faut surtout voir si le fichier log est recréé à chaque fois ou si tu estimes utile / intéressant de garder une trace des erreurs dans le temps.

En effet, bien que destiné "prioritairement" au séquenceur, ce fichier log pourrait te permettre de créer une historique des problèmes rencontrés, et, pourquoi pas, t'aider dans la résolution de ceux-ci...

Dés lors, après ouverture du fichier, il te "suffirait" de chercher le dernier "[" et d'en tester le contenu pour savoir si c'est d'une manière générale "cohérent" avec le moment où le séquenceur aura appelé la commande

Mais effectivement, ce n'est qu'un exemple, et je pars sans doute beaucoup trop loin

Autre question: qu'est-ce que tu entends par "contexte dans lequel l'erreur est apparue"?

Ce peut être à peu près tout et n'importe quoi... j'aurais tendance à fournir le chemin d'appel des fonctions qui ont mené à l'erreur.

Cela te permettra, justement, de savoir en quoi l'appel de l'application avec les paramètres que tu as fournis a mené à produire cette erreur, et, encore une fois, c'est susceptible de t'apporter des précisions intéressantes voire importantes pour la résolution de l'erreur

[Spout]

Ok, je vais prendre en compte ces remarques pour définir mon fichier de trace, vu qu'apparemment il n'y a que comme ça que je pourrais mon sortir.
Merci pour ces avis!