Re: gérer des fichiers log

Le 19-12-2021, Thomas <fantome.forums.tDeContes@free.fr.invalid> a écrit :

>
- on peut tout ignorer en cas de pb avec l'interface graphique, parce
que ça ne peut pas arriver uniquement à cet endroit, ça arrivera
forcément ailleurs.

Ben justement voilà justement une bonne raison de ne pas chercher à
logguer à plein d'endroits différents en fonction du contexte. Imagine,
ton application elle tourne nickel en terminal. Ton utilisateur veut
l'utiliser avec l'interface graphique. Sauf que comme tu n'as pas
exactement les mêmes librairies avec Wayland et Xorg, ça peut marcher
sur l'un et pas sur l'autre.

Si tu veux analyser tous les cas possibles, ça va être très délicat. Si
tu te contentes de balancer les logs et de laisser l'utilisateur en
faire ce qu'il veut ça te simplifie la vie.

en cas de pb avec stdout / stderr,

Ce qui est bien avec stdout/stderr, c'est que s'il y a un problème,
l'utilisateur le redirige vers un autre endroit où il n'y a pas de
problème.

- si l'interface graphique est disponible, on affiche ça dedans,
parce que dans ce cas c'est probable que stdout et stderr ne soient pas
lus (redirigés ou jetés).

L'affichage dans l'interface graphique, c'est pour afficher une
information qui demande une intervention de l'utilisateur à un moment.
C'est pas forcément une erreur.

Par exemple, si l'utilisateur n'a pas choisi la couleur de son fond
d'écran mais que tu as une couleur par défaut, c'est pas très important.
Lorsqu'il change la couleur de son fond d'écran mais qu'il y a un
problème et que tu gardes la couleur par défaut, il faut l'informer que
son action s'est mal passée.

Si par contre, ton application exécute une action en tâche de fond
toutes les minutes, si l'action plante une fois sur deux, il faut le
logguer mais ne pas lui afficher la pop-up toutes les deux minutes. Ce
n'est pas forcément grave si stdout et stderr ne sont pas lus. Si
l'utilisateur veut chercher à comprendre après coup, il les lira.

- si non, on l'envoie sur stdout,
parce que dans ce cas c'est probable que stderr ne soit pas lu
(redirigé),
mais c'est probable que stdout le soit (directement dans un terminal).

En fait, l'intérêt de sdout et de stderr, c'est que tu t'en cognes de
savoir si c'est lu ou pas, redirigé ou pas. Tu donnes une information et
l'utilisateur en fait ce qu'il veut.

La différence entre les deux, c'est que le stdout, c'est pour
l'information normale et le stderr c'est pour l'erreur. Par exemple, si
ton application exécute une tâche de fond toutes les minutes, dans ton
stdout, tu vas logguer le début et la fin de l'action. Et s'il y a un
plantage, tu loggues l'erreur dans le stderr.

Comme ça, si l'utilisateur redirige tout dans le même fichier, il aura
le contexte : le plantage aura eu lieu pendant la tâche de fond. Mais
s'il veut se concentrer sur les erreurs, il ne regarde que stderr. Tu le
laisses choisir le niveau d'information qu'il veut afficher.

Et si dans tes logs, tu précises ce que c'est (avec un timestamp devant) :
INFO: début de la tâche de fond
INFO: 42 informations à mettre à jour
WARNING: 1 mise à jour est vide, utilisation de la valeur TOTO
ERROR: enregistrement impossible, droits insuffisants
INFO: fin de la tâche de fond

Là, comme en général, tu vas avoir des centaines de lignes d'info pour
quelques lignes d'erreur, il va pouvoir faire des recherches faciles.

Par exemple, tu mets
du
DEBUG, INFO, WARNING et ERROR quand tu envoies tes logs avec un
niveau
d'activation faible en temps normal

>
est-ce que je numérote dans cet ordre de 0 à 3 ?

En général, le plus simple est d'utiliser un framework qui fait déjà
tout ça et de suivre la doc.

--
Si vous avez du temps à perdre :
https://scarpet42.gitlab.io