Commentaires pour Blog Xebia France

Commentaires sur Java en Production – L’audit par Cyrille Le Clerc

Cyrille Le Clerc — Mon, 06 Sep 2010 22:23:57 +0000

@Stéphane,

Merci d’avoir relevé la contradiction, vous nous avez pris en flagrant délit de « retournement de veste » .
Nous nous sommes rendu compte que les risques de mauvaise manipulation du fichier de configuration du framework de logs et que développer une surcouche aux appenders du framework de log pour isoler les configurations représente rapidement une charge de travail très importante et dissuasive.

Moralité, nous profitons du fichier de configuration des loggers même si ce n’est pas très orthodoxe et nous séparons les fichiers d’output : le fichier d’audit qui grossit en permanence est différent du fichier de logs qui ne bouge qu’en cas de dysfonctionnement.

Nous allons mettre à jour le billet sur les dix commandements des logs.

Cyrille

Commentaires sur Des ESBs et des nuages par Revue de presse, semaine 35 - Espace de fouille

Revue de presse, semaine 35 - Espace de fouille — Mon, 06 Sep 2010 08:36:38 +0000

[...] Des ESBs et des nuages [...]

Commentaires sur Java en Production – L’audit par Stéphane

Stéphane — Fri, 03 Sep 2010 11:03:43 +0000

Article intéressant mais si je ne me trompe vous allez contre le commandement 9 de l’article suivant.
http://blog.xebia.fr/2008/07/11/les-10-commandements-des-logs-applicatives/

Commentaires sur Revue de Presse Xebia par Sebastien

Sebastien — Wed, 01 Sep 2010 09:24:21 +0000

@adiGuba

Je suis bien d’accord que si le close() modifie l’état de la ressource (flush du buffer) alors une exception dans le close() doit être remontée et le traitement interrompu. D’où ma précision sur l’appel de flush().

Commentaires sur Revue de Presse Xebia par adiGuba

adiGuba — Wed, 01 Sep 2010 07:13:49 +0000

@Stephane : Il y a une discussion sur l'intégration de cela automatiquement dans le try/finally, mais cela pose un problème de compatibilité.

Regarde ce code :

try {
throw new A();
} finally {
throw new B();
}

Quel est l'exception qui doit être remontée ? Et quel est celle qui doit être ajouté dans les "suppressed-exceptions" ?

La logique voudrait qu'on remonte A en cachant B, car A est l'exception d'origine, mais on obtient alors un comportement totalement différent de ce qui est fait actuellement (seul B est remontée)
Il faudrait faire l'inverse pour rester compatible, mais on obtient alors l'inverse de ce qui est souhaité...

Mais en fait, ce problème se pose principalement sur la gestion des ressources. Je ne vois pas beaucoup de cas où l'on a besoin de traiter des exceptions dans un finally.

Enfin, les exceptions ne sont pas mutable. La méthode initCause() permet déjà de modifier le stacktrace...

@Sebastien : La plupart du temps le close() ne génèrera pas d'exception (et du coup les deux solutions ne posent aucun problème).

Mais lorsqu'on utilise des flux bufférisé ou un peu plus évolué, il est possible que le close() écrivent des données sur le disque. Dans ce cas là ignorer l'exception pourrait poser quelque problème car on ne pourra pas détecter les erreurs d'écriture.

Imagine un code comme celui-ci qui déplace un fichier (copie puis suppression du fichier d'origine) :

copyFile(a, b);
a.delete();

En cas d'erreur lors du close() pour X raison, le fichier peut être corrompu.
En ignorant l'exception on continuera normalement en supprimant notre fichier source...

Avec le code de l'article on ne peut pas détecter cela programmatiquement.
Avec le pattern d'un try/finally par ressource on recevra bien l'exception.

a++