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 Newsgroups: fr.comp.os.unix Mail-Copies-To: nobody Subject: Re: =?UTF-8?Q?g=C3=A9rer?= des fichiers log References: 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: 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 , Stéphane CARPENTIER wrote: > Le 19-12-2021, Thomas 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/