je pense que ma question est un peu HS, mais j'aimerais profiter de votre
expérience à tous en la matière pour me conseiller, et répondre aux quelques
questions que je me pose.
J'aimerais ajouter un système de log à mon appli, pour déterminer plus
rapidement la source d'une erreur.
Quelles librairies existent en C++ pour ça? J'ai essayé log4cpp, mais
apparement ça fonctionne pas avec BCB6. J'ai aussi entendu parler d'une
librairie chez boost, mais j'ai pas trouvé.
Quelles sont les actions que vous mettez en log ds vos applis? Je sais déjà
que je vais logger les échanges avec une base de données, ainsi que les
échanges avec DirectX. Mais dans le code "normal", comment distinguer ce qui
vaut la peine de l'être?
J'imagine que c'est abusif de tout logger...
Enfin, comment déterminer lorsqu'une exception ou une assertion est lancée,
tout le parcours du code dans les diverses fonctions de l'appli, pour
permettre de remonter facilement à la source? (Un peu comme le fait le
debugger en somme)
Cette action est irreversible, confirmez la suppression du commentaire ?
Signaler le commentaire
Veuillez sélectionner un problème
Nudité
Violence
Harcèlement
Fraude
Vente illégale
Discours haineux
Terrorisme
Autre
Michael DOUBEZ
Bonsoir à tous,
je pense que ma question est un peu HS, mais j'aimerais profiter de votre expérience à tous en la matière pour me conseiller, et répondre aux quelques questions que je me pose.
J'aimerais ajouter un système de log à mon appli, pour déterminer plus rapidement la source d'une erreur.
Quelles librairies existent en C++ pour ça? J'ai essayé log4cpp, mais apparement ça fonctionne pas avec BCB6. J'ai aussi entendu parler d'une librairie chez boost, mais j'ai pas trouvé.
Surement dans le vault: http://boost-consulting.com/vault/
Je ne l'ai jamais essayé.
Quelles sont les actions que vous mettez en log ds vos applis? Je sais déjà que je vais logger les échanges avec une base de données, ainsi que les échanges avec DirectX. Mais dans le code "normal", comment distinguer ce qui vaut la peine de l'être?
J'imagine que c'est abusif de tout logger...
Généralement, je logge différemment quand je suis en mode debug ou en mode release. En mode debug, je met des infos de tracage qui n'apparaissent pas dans le mode release (assez verbose).
Maintentant, concernant quoi logger ? Bien évidement les erreurs (fatal et recovered), pour une base de données je n'ai pas d'expérience mais je suppose les opérations de log/delog de session, commit, rollback.
Enfin, comment déterminer lorsqu'une exception ou une assertion est lancée, tout le parcours du code dans les diverses fonctions de l'appli, pour permettre de remonter facilement à la source? (Un peu comme le fait le debugger en somme)
Si l'exception ne te le dit pas, tu n'as pas moyen de le savoir car la stack est dépilée. Le but est un bonne utilisation des try/catch comme par exemple mettre des try aux frontières des modules utilisés et logger l'exception reçue avant de la renvoyer plus haut si tu ne sais pas la gérer de façon locale.
Ca peut être bien aussi de te faire un fichier qui spécifie comment tu vas gérer les situation d'erreur (impossible d'écrire un fichier ...); ca permet de savoir comment et à quel niveau les intercepter. Bon courage :)
Michael
Bonsoir à tous,
je pense que ma question est un peu HS, mais j'aimerais profiter de votre
expérience à tous en la matière pour me conseiller, et répondre aux quelques
questions que je me pose.
J'aimerais ajouter un système de log à mon appli, pour déterminer plus
rapidement la source d'une erreur.
Quelles librairies existent en C++ pour ça? J'ai essayé log4cpp, mais
apparement ça fonctionne pas avec BCB6. J'ai aussi entendu parler d'une
librairie chez boost, mais j'ai pas trouvé.
Surement dans le vault:
http://boost-consulting.com/vault/
Je ne l'ai jamais essayé.
Quelles sont les actions que vous mettez en log ds vos applis? Je sais déjà
que je vais logger les échanges avec une base de données, ainsi que les
échanges avec DirectX. Mais dans le code "normal", comment distinguer ce qui
vaut la peine de l'être?
J'imagine que c'est abusif de tout logger...
Généralement, je logge différemment quand je suis en mode debug ou en
mode release. En mode debug, je met des infos de tracage qui
n'apparaissent pas dans le mode release (assez verbose).
Maintentant, concernant quoi logger ? Bien évidement les erreurs (fatal
et recovered), pour une base de données je n'ai pas d'expérience mais je
suppose les opérations de log/delog de session, commit, rollback.
Enfin, comment déterminer lorsqu'une exception ou une assertion est lancée,
tout le parcours du code dans les diverses fonctions de l'appli, pour
permettre de remonter facilement à la source? (Un peu comme le fait le
debugger en somme)
Si l'exception ne te le dit pas, tu n'as pas moyen de le savoir car la
stack est dépilée. Le but est un bonne utilisation des try/catch comme
par exemple mettre des try aux frontières des modules utilisés et logger
l'exception reçue avant de la renvoyer plus haut si tu ne sais pas la
gérer de façon locale.
Ca peut être bien aussi de te faire un fichier qui spécifie comment tu
vas gérer les situation d'erreur (impossible d'écrire un fichier ...);
ca permet de savoir comment et à quel niveau les intercepter. Bon courage :)
je pense que ma question est un peu HS, mais j'aimerais profiter de votre expérience à tous en la matière pour me conseiller, et répondre aux quelques questions que je me pose.
J'aimerais ajouter un système de log à mon appli, pour déterminer plus rapidement la source d'une erreur.
Quelles librairies existent en C++ pour ça? J'ai essayé log4cpp, mais apparement ça fonctionne pas avec BCB6. J'ai aussi entendu parler d'une librairie chez boost, mais j'ai pas trouvé.
Surement dans le vault: http://boost-consulting.com/vault/
Je ne l'ai jamais essayé.
Quelles sont les actions que vous mettez en log ds vos applis? Je sais déjà que je vais logger les échanges avec une base de données, ainsi que les échanges avec DirectX. Mais dans le code "normal", comment distinguer ce qui vaut la peine de l'être?
J'imagine que c'est abusif de tout logger...
Généralement, je logge différemment quand je suis en mode debug ou en mode release. En mode debug, je met des infos de tracage qui n'apparaissent pas dans le mode release (assez verbose).
Maintentant, concernant quoi logger ? Bien évidement les erreurs (fatal et recovered), pour une base de données je n'ai pas d'expérience mais je suppose les opérations de log/delog de session, commit, rollback.
Enfin, comment déterminer lorsqu'une exception ou une assertion est lancée, tout le parcours du code dans les diverses fonctions de l'appli, pour permettre de remonter facilement à la source? (Un peu comme le fait le debugger en somme)
Si l'exception ne te le dit pas, tu n'as pas moyen de le savoir car la stack est dépilée. Le but est un bonne utilisation des try/catch comme par exemple mettre des try aux frontières des modules utilisés et logger l'exception reçue avant de la renvoyer plus haut si tu ne sais pas la gérer de façon locale.
Ca peut être bien aussi de te faire un fichier qui spécifie comment tu vas gérer les situation d'erreur (impossible d'écrire un fichier ...); ca permet de savoir comment et à quel niveau les intercepter. Bon courage :)
Michael
Alp Mestan
Si l'exception ne te le dit pas, tu n'as pas moyen de le savoir car la stack est dépilée. Le but est un bonne utilisation des try/catch comme par exemple mettre des try aux frontières des modules utilisés et log ger l'exception reçue avant de la renvoyer plus haut si tu ne sais pas la gérer de façon locale.
Ca peut être bien aussi de te faire un fichier qui spécifie comment tu vas gérer les situation d'erreur (impossible d'écrire un fichier ...); ca permet de savoir comment et à quel niveau les intercepter. Bon coura ge :)
Je me permettrais de rajouter que comme l'a dit Michael Doubez, il s'agit de différencier à la fois le mode de compilation (Debug/ Release) et le niveau du log(tracking, warning, fatal error, ...). En suivant ce fil directeur, en Debug bien sûr tu vas tout afficher dans un fichier. En Release, je dirais qu'à la limite il y a les warnings, mais sinon ne logger que les erreurs fatales et autres erreurs d'ordre égal.
Pour résumer : tu peux et il est même conseillé de tout logger en Debug. En Release tu dois limiter au strict minimum. Donc pas de messages du genre "Connexion BDD : Ok" ou autres mais seulement les erreurs importantes je pense. Enfin je procède ainsi.
Alp Mestan
Si l'exception ne te le dit pas, tu n'as pas moyen de le savoir car la
stack est dépilée. Le but est un bonne utilisation des try/catch comme
par exemple mettre des try aux frontières des modules utilisés et log ger
l'exception reçue avant de la renvoyer plus haut si tu ne sais pas la
gérer de façon locale.
Ca peut être bien aussi de te faire un fichier qui spécifie comment tu
vas gérer les situation d'erreur (impossible d'écrire un fichier ...);
ca permet de savoir comment et à quel niveau les intercepter. Bon coura ge :)
Je me permettrais de rajouter que comme l'a dit Michael Doubez, il
s'agit de différencier à la fois le mode de compilation (Debug/
Release) et le niveau du log(tracking, warning, fatal error, ...). En
suivant ce fil directeur, en Debug bien sûr tu vas tout afficher dans
un fichier. En Release, je dirais qu'à la limite il y a les warnings,
mais sinon ne logger que les erreurs fatales et autres erreurs d'ordre
égal.
Pour résumer : tu peux et il est même conseillé de tout logger en
Debug. En Release tu dois limiter au strict minimum. Donc pas de
messages du genre "Connexion BDD : Ok" ou autres mais seulement les
erreurs importantes je pense. Enfin je procède ainsi.
Si l'exception ne te le dit pas, tu n'as pas moyen de le savoir car la stack est dépilée. Le but est un bonne utilisation des try/catch comme par exemple mettre des try aux frontières des modules utilisés et log ger l'exception reçue avant de la renvoyer plus haut si tu ne sais pas la gérer de façon locale.
Ca peut être bien aussi de te faire un fichier qui spécifie comment tu vas gérer les situation d'erreur (impossible d'écrire un fichier ...); ca permet de savoir comment et à quel niveau les intercepter. Bon coura ge :)
Je me permettrais de rajouter que comme l'a dit Michael Doubez, il s'agit de différencier à la fois le mode de compilation (Debug/ Release) et le niveau du log(tracking, warning, fatal error, ...). En suivant ce fil directeur, en Debug bien sûr tu vas tout afficher dans un fichier. En Release, je dirais qu'à la limite il y a les warnings, mais sinon ne logger que les erreurs fatales et autres erreurs d'ordre égal.
Pour résumer : tu peux et il est même conseillé de tout logger en Debug. En Release tu dois limiter au strict minimum. Donc pas de messages du genre "Connexion BDD : Ok" ou autres mais seulement les erreurs importantes je pense. Enfin je procède ainsi.
Alp Mestan
Michael
Ok, merci de tes conseils
Et c'est je pense à l'utilisation que je vais savoir quoi et quand logger les choses qui me paraissent essentielles...
Sinon c'est bien dans le Vault que j'ai trouvé boost logger
Merci à tous les 2
Mike
Ok, merci de tes conseils
Et c'est je pense à l'utilisation que je vais savoir quoi et quand logger les
choses qui me paraissent essentielles...
Sinon c'est bien dans le Vault que j'ai trouvé boost logger
