tags pour les logs

In article <slrnsl18t8.29t.sc@scarpet42p.localdomain>,
 Stéphane CARPENTIER <sc@fiat-linux.fr> wrote:

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

In article <slrnsks8om.83t.sc@scarpet42p.localdomain>,
 Stéphane CARPENTIER <sc@fiat-linux.fr> wrote:

Pour la séparation de stdout et stderr, c'est pas forcément très utile.
Il me semble préférable de tout mettre au même endroit avec un niveau de
log qui contient un tag et qui est paramétrable. Par exemple, tu mets du
DEBUG, INFO, WARNING et ERROR quand tu envoies tes logs avec un niveau
d'activation faible en temps normal pour avoir moins de lignes et tu
affiches tout quand tu veux comprendre ce qu'il se passe.

>
j'aime bcp l'idée :-)
>
je ne sais pas si c'est facile à faire très rapidement, parce que :
- il faut que je définisse des règles pour catégoriser les logs
(auj dans mon code les logs ne sont divisés qu'en 2 catégories : DEBUG
et ERROR)

au fur et à mesure que je parcours mon code, je vois de mieux en mieux
comment il faudrait que je repartisse les msgs dans chaque catégorie.

j'aurais même envie d'ajouter :
- les erreurs critiques, quand le logiciel se retrouve dans un état tel
qu'il est contraint de se terminer immédiatement,
- les erreurs d'usage, dues à un mesusage de l'utilisateur,
- éventuellement, les erreurs dues à des données d'entrée incohérentes,
si elles nécessitent d'être distinguées des simples bugs de programme.

est-ce une mauvaise idée ?

- il faut que je réfléchisse à comment j'organise une ligne, pour que ça
soit agréable à la fois
  - à utiliser en traitement automatique (c'était ça ton idée ?),
  - quand on l'affiche dans un terminal, en évitant de mettre des
caracteres de contrôle qui vont fiche le bazar ...

est-ce que ça convient, d'avoir tous ces tags qui s'affichent dans le
terminal quand on est en CLI (par ex au moment d'indiquer que les
arguments sont mauvais) ?

 
Si c'est une application qui tourne dans un terminal, faut pas que les
logs la rendent inutilisable.

C'est pareil pour ton
application, il faut qu'elle soit souple.

j'ai pas avancé là dessus : je ne sais pas comment faire ça bien.

là où je butte c'est que les sorties standard devraient à la fois servir
pour la production de logs, avec tags & horodatage,
et à la fois ne pas être surchargées, pour le cas où l'utilisateur
afficherais ça dans son terminal.

--
RAPID maintainer
http://savannah.nongnu.org/projects/rapid/