Path: ...!weretis.net!feeder6.news.weretis.net!feeder8.news.weretis.net!2.eu.feeder.erje.net!feeder.erje.net!fdn.fr!usenet-fr.net!agneau.org!nntpfeed.proxad.net!proxad.net!feeder1-1.proxad.net!cleanfeed1-a.proxad.net!nnrp4-2.free.fr!not-for-mail
From: Thomas <fantome.forums.tDeContes@free.fr.invalid>
Newsgroups: fr.comp.os.unix
Mail-Copies-To: nobody
Subject: Re: =?UTF-8?Q?g=C3=A9rer?= des fichiers log
References: <fantome.forums.tDeContes-AD48E3.21414905072021@news.free.fr> <scubs2$u25$2@shakotay.alphanet.ch> <fantome.forums.tDeContes-F23835.20444917072021@news.free.fr> <sd0l91$b4m$1@shakotay.alphanet.ch> <fantome.forums.tDeContes-130E7D.23050920072021@news.free.fr> <sd8faa$8ac$1@shakotay.alphanet.ch> <fantome.forums.tDeContes-433B13.01575723072021@news.free.fr> <sddoan$flh$1@shakotay.alphanet.ch> <fantome.forums.tDeContes-5442BA.19235419092021@news.free.fr> <si9urh$mad$1@shakotay.alphanet.ch> <fantome.forums.tDeContes-D7C707.17401124092021@news.free.fr> <slrnsks8om.83t.sc@scarpet42p.localdomain> <fantome.forums.tDeContes-AD18A9.03233926092021@news.free.fr> <slrnsl18t8.29t.sc@scarpet42p.localdomain> <fantome.forums.tDeContes-CB5B35.17330627092021@news.free.fr> <slrnslefar.16n.sc@scarpet42p.localdomain> <fantome.forums.tDeContes-BF832B.23415822102021@news.free.fr> <fantome.forums.tDeContes-B2A88C.19191319122021@news.free.fr> <slrnssmcu2.hi0.sc@scarpet42p.localdomain>
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit
User-Agent: MT-NewsWatcher/3.5.3b3 (Intel Mac OS X)
Date: Sun, 02 Jan 2022 00:54:25 +0100
Message-ID: <fantome.forums.tDeContes-E3C660.00542502012022@news.free.fr>
Lines: 104
Organization: Guest of ProXad - France
NNTP-Posting-Date: 02 Jan 2022 00:54:25 CET
NNTP-Posting-Host: 91.175.52.121
X-Trace: 1641081265 news-2.free.fr 6458 91.175.52.121:11660
X-Complaints-To: abuse@proxad.net
Bytes: 6089

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

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

> > 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.

pour ça il faut qu'il s'aperçoive du pb, puis qu'il redémarre 
l'application avec les bons paramètres.
c'est pour ça (je crois) que tu m'avais dit que c'était pas bien 
d'ignorer les erreurs.


> 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 le disque est plein,
- il faut le logguer ou ?
- tu trouves que ça ne convient pas de signaler ce pb dans l'interface 
graphique ?
ça ne convient pas de considérer que ce pb doit être résolu 
immédiatement pour que le logiciel puisse continuer à fonctionner 
correctement ?

> 
> 
> > - 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.

et si le disque est plein ?


> 
> 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.

c'est comme ça que je suis parti pour l'instant.

> 
> 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.

a priori c'est une idée que je trouve pas mauvaise.

mais il y a des questions non répondues, dans mon msg du 22 Oct 2021, 
qui font que je n'y vais pas pour l'instant.


> 
> >> > >> >> 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.

en ada, on a à ma connaissance toutes les bibliothèques nécessaires pour 
avoir toutes les possibilités de développement à disposition, 
mais il n'y a pas autant de bibliothèques qu'en c quand même.

je suppose que c'est pour ça que mon prédécesseur avant démarré 
l'écriture d'une telle bibliothèque.

je l'ai immédiatement "améliorée" en ajoutant la génération de 
fichiers log, parce que c'était un besoin et que je ne savais pas que 
c'était mal vu.
et là, je continue de l'améliorer, par ex en rendant ces fichiers log 
facultatifs, et en permettant de choisir leur nom.

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