Discussion :

[mermich]

Imaginons un système de batch, j'ai sûrement envie de savoir dans mes logs, le temps qu'à pris un gros batch, quelques infos sur les fichiers reçus (genre la taille et qui les envoie)...

Dans ce cas ce n'est pas des logs mais de l'audit de perfmances, dans ce cas un fichier specialiser pour les performances peut etre utile ou carrement une table/base de donnees propre a l'audit qui peut etre requetee.

[ddoumeche]

Les logs dont monsieur le seigneur (euh sénior) nous parle sont des logs au cours d'exécution de la méthode (notez que je vais parler que de programmation objet).
Normalement une méthode n'a pas 50 milles trucs à faire, sinon on est dans un mauvais design (eq pas très bon développeur).
Donc si notre méthode est suffisamment bien construite alors juste le log des appels de méthode suffit. Un des cas d'école de la programmation par aspect.

Tout ça pour dire que si le code est bien construit aucun log ne devrait être écrit. Mais bon on est pas parfait et donc on doit en mettre quand même de temps en temps.

Dans un monde parfait, on ferait de la programmation par contrat et les méthodes ne planteraient pas.

[EpiTouille]

Je signale juste une typo dans le titre de l'article (enfin dans le fils des actualités) :

[DonQuiche]

Dans un monde parfait, on ferait de la programmation par contrat et les méthodes ne planteraient pas.

Et les contrats représenteraient 90% du code, les coûts de développement seraient dix fois importants, la compilation durerait une minute, et les programmeurs débogueraient les contrats.


Les contrats, comme les tests ou les spécifications, sont avant tout une autre façon, peu compacte et partielle mais intentionnelle et plus compréhensible, d'exprimer le programme. C'est avant tout la redondance de ces modes d'expression qui entraîne la fiabilité. Une bonne solution dans les domaines où l'on a besoin de garanties fortes mais une solution coûteuse et fastidieuse.

[Bousk]

Cela ca t'avances a quoi de plus que verifier les entrees sorties et envoyer une exeption, de plus un api externe devrait toujours etre imbriquee dans un autre conteneur (cf clean code ou code complete pour plus de details et explications).

Entre autre à savoir que le flow normal ne s'est pas déroulé à cause d'une erreur de leur côté et non du tien. Et ça n'a rien à voir avec la validité des entrées.

[Luckyluke34]

Dans un monde parfait, on ferait de la programmation par contrat et les méthodes ne planteraient pas.

Sauf celles qui font de l'I/O quand l'I/O est défaillant Et les erreurs de programmation genre récursion infinie.

Mais je suis plutôt d'accord avec le billet de blog. Pour moi il y a deux grandes sortes de log : les logs d'erreur et les journaux applicatifs.

Dans certains domaines, il est obligatoire (légalement ou par politique interne) de journaliser les actions les plus importantes qui surviennent. Des transactions sont mêmes mises en place pour assurer l'atomicité de (exécution de l'opération + logging). Si on ne peut pas logger, on ne fait pas l'action.

J'aime bien les approches comme Event Sourcing, la partie journalisation est "gratuite" car la couche persistance stocke déjà une suite d'événements plutôt qu'un état en base de données. On a toute la frise chronologique du runtime, il n'y a plus qu'à exploiter les données.

De manière générale, je pense aussi qu'il faut faire basculer un maximum de choses du monde des exceptions vers le monde des événements business normaux dans la vie d'une application. Les exceptions sont en général plus coûteuses en termes de performances, plus fragilisantes pour l'exécution et plus difficiles à exploiter correctement. Avec une bonne analyse métier, il est souvent facile de changer une exception (sur des accès concurrents par exemple) en un déroulement applicatif normal qui peut s'inspirer de ce qui se passe dans la vie réelle (file d'attente, retry, etc.) Ca se retrouve aussi dans les logs mais c'est moins disruptif.

[sekaijin]

Quand je lis que lorsque on a fait un bon design alors le log des appels de méthode suffit je me marre.

nos amis de la Business Machine nous on pondu un tel truc
effectivement super facile de localiser l'endroit où se produit l'erreur.

J'avais (oui on à fini par les mettre à la porte et à développer sérieusement) tous le cheminement des appels successif jusqu'à l'erreur.
Je pouvais donc savoir où mais comme je n'avais que ça impossible de savoir pourquoi.

supposant que nous ayons disons 5 classes avec chacun 4 méthodes. et que pour toutes ces méthode nous aillons été très rigoureux et traçons chaque appel.
tout cela est plutôt simple. mais voilà le système instancie des milliers d'exemplaire de ces classes assure des centaines de traitement en parallèle le tout pour traiter des millions de données différentes.
du coup dans les logs les appels simultanés à ces quelque classes se retrouve dispersés.

et voila comment sur une simple exécution d'une requête on sait qu'on a à la ligne 35 de la méthode toto de la classe Titi une erreur SQL "Table or View dose not exist"
Mais on ne sais pas qu'elle table parmi les quelques dizaines de milliers qui sont présente dans les quelques centaine de bases, pas plus q'on ne sait quelle requête ni pour quelle donnée. ne riez pas c'est IBM qui a produit ça.

Alors on a envie de mettre des log bien plus précis et on se retrouve avec des fichier de log qui font plus d'une rotation par minute. et comment ils sont encore une fois inexploitable.

bref si les log permettaient à eux seul de faire du debug ça se saurait depuis longtemps.

A+JY