Récupération des erreurs d'une appli console win32

Salut à tous

Je travaille sur un grosse application console win32 qui de temps en temps plante pour des raisons non encore définie. J'aimerais savoir s'il est possible de récupérer les erreur quelque part. Ceci afin d'informer l'utilisateur que ça a planté et éventuellement savoir pourquoi.

Pour test j'ai écrit ce tout petit bout de code qui provoque une erreur.

Code:

---

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15

int _tmain(int argc, _TCHAR* argv[]) { printf_s("Cette application plante et c'est normal"); double x = 3.1416e-3; double y = 5; double *p=NULL;//permet de générer une erreur   for (int n = 0; n < 10; n++) { *p= x / y; y -= 1; } return 0; }

---

• Quand je le lance sous visual studio il me met un message comme quoi j'ai un pointeur null.
• Si je le lance dans une fenêtre invite de commande. Je n'ai pas de retour. Windows me génère juste une fenêtre qui indique que mon application à planter et que windows recherche une solution.
• Si je fais exécuter cette application via une application en java (mode de fonctionnement normal pour l'application réelle) je n'ai aucun retour.

Quelqu'un aurait il une idée?

Tu dois pouvoir faire ça avec du Structured Exception Handling, en mettant un log dans ton Exception Filter:

Code:

---

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40

int MyExceptionFilter(DWORD exceptionCode, LPEXCEPTION_POINTERS exceptionPointers) { fprintf(stderr, "SEH exception of type %08lX! Terminating.\n", exceptionCode); FILE * logFile = fopen("logfile.txt", "a"); if(logFile != NULL) { fprintf(logFile, "SEH exception of type %08lX! Terminating.\n", exceptionCode); switch(exceptionCode) { case EXCEPTION_ACCESS_VIOLATION: /*Logguer les infos supplémentaires dans exceptionPointers*/ break; } fclose(logFile); } return EXCEPTION_CONTINUE_SEARCH; }     int _tmain(int argc, _TCHAR* argv[]) { __try { printf_s("Cette application plante et c'est normal"); double x = 3.1416e-3; double y = 5; double *p=NULL;//permet de générer une erreur   for (int n = 0; n < 10; n++) { *p= x / y; y -= 1; } return 0; } __except(MyExceptionFilter(GetExceptionCode(), GetExceptionInformation()) { return GetExceptionCode(); /*Ne sera pas exécuté de toute façon*/ } }

---

Bonne idée mais je crains de ne pas pouvoir l'appliquer dans ma grosse application car il faudrait que je mette des __try/ __except un peu partout.
Sinon j'ai pensé à un système du type chien de garde.

Note que le code que j'ai posté ne permet pas de "récupérer" l'erreur, mais d'informer l'utilisateur quand le programme plante.
Il ne convient pas de considérer une Access Violation comme une erreur "récupérable" si on ne l'a pas provoquée sciemment dans des conditions contrôlées.

Là, je vais encore faire mon ayatollah, désolé Médinoc. :mouarf:

On ne catch pas une exception qu'on ne traite pas (logguer n'est pas traite).

Votre application console n'est pas l'application frontale de l'utilisateur, ça serait mal venu qu'elle affiche des messages d'erreurs hors du contexte d'utilisation de l'utilisateur final. En bref, c'est plus à l'application JAVA de se démerder pour expliquer à son utilisateur que votre application console est partie en sucette (et elle peut avoir des roues de secours, elle).

L'approche que je vous conseille et que vous semblez envisager, c'est celle des WatchDog.

Pour avoir un système sympa, je vous conseillerai d'utiliser des outils comme ADPlus qui permettent d'automatiser la configuration et la génération de fichier de dump en cas de crash d'une application.

L'application JAVA lance le WatchDog et communique avec celui-ci.
Le WatchDog lance votre application console en ayant configuré DrWatson / ADPlus pour avoir un dump en cas de crash.
Le WatchDog peut relancer l'application console ou répondre à l'application JAVA avec le code d'erreur qui va bien.

EXCEPTION_CONTINUE_SEARCH signifie que je ne la catche pas.

Citation:

---

Envoyé par bacelar

Votre application console n'est pas l'application frontale de l'utilisateur, ça serait mal venu qu'elle affiche des messages d'erreurs hors du contexte d'utilisation de l'utilisateur final. En bref, c'est plus à l'application JAVA de se démerder pour expliquer à son utilisateur que votre application console est partie en sucette (et elle peut avoir des roues de secours, elle).

---

Oui c'est tout à fait ça. L'application console réalise des calculs qui peuvent être très long et ce qui pose problème à l'utilisateur c'est que parfois dans le cas ou l'application plante il ne le sait pas. Normalement il y a un suivit de la progression des calculs mais il peut être lent. Si je ne récupère pas l'erreur ce n'est pas vraiment un problème. Il faut juste que je mette un message "L'application a planté inutile d'attendre".

Je vais jeter un oeil à ADPlus

J'avais parlé de DrWatson et d'ADPlus pour générer des dump et donc faire de l'analyse de bugs "sur terrain".

Si le problème est plus de l'ordre du feedback à l'application JAVA, j'ai du mal à comprendre pourquoi la valeur de retour de l'exécution du process ne suffit pas ?

Le watchdog, c'est plus pour relancer automatiquement le processus qui à planté.

Effectivement je n'avais pas pensé au retour d’exécution. Je pensais pouvoir avoir un message du type de celui que donne le debbuger. Certain module de cette application sont en Fortran et il retourne des messages d'erreur mais pas les parties en C++ :(