Je vais tout d'abord commencer par vous présenter le contexte d'éxécution, car comme vous le constaterez par la suite, il a son importance.

Je développe sous FreeBSD, un système d'exploitation de type UNIX qui fait massivement appel à la compilation lors de l'installation d'applications tierces.

Du coup, la première chose que je fais lorsque je l'installe est de mettre en place ccache, un système de cache pour gcc qui permet d'accélérer grandement les compilations en ne faisant pas le même travail plusieurs fois.

Corrolaire, il est gourmand en espace disque puisqu'il faut bien stocker quelque part le résultat des compilations.

Parallélement à cela, j'ai un très haut niveau de journalisation au niveau d'httpd et de mysql, puisqu'il s'agit d'une machine de développement et que pouvoir tracer finement ce qu'il se passe peut être extrémement intructif lors de la conception et/ou la correction d'un code.

En conséquence, ma partition /var peut vite se retrouver remplie, pour peu que je génére une boucle infinie en PHP et que je compile une polymégachié beaucoup d'applications, surtout si j'ai oublié de faire le ménage depuis un moment dans /var/tmp et /var/log, ce qui était le cas au moment des faits, car j'ai autre chose à faire actuellement.

Maintenant que le contexte d'éxécution est posé, je vais à présent vous présenter le code qui m'a posé problème, ou plutôt qui a révélé le problème.

Pour des raisons qui me sont propres, quelque part dans mon code, j'ai ces deux lignes de code :

<?php
...
ini_set('error_log', '/var/tmp/fichierQuiVaBien.log');
ini_set('display_errors', 0);
...
?>

Ensuite, dans le code qui suit, j'ai fais une erreur (pour la petite histoire, je n'ai pas préfixé avec \ un appel au constructeur de la classe arrayIterator alors que j'étais dans un espace de nommage).

Evidement, lors de l'éxécution, j'ai eu un problème puisque mon code ne produisait pas le résultat attendu.

Et en fait, pour être précis, je n'ai pas eu un mais deux problème, puisque je n'ai eu aucun retour de la part de PHP au sujet du problème qu'il a rencontré, visuellement ou dans dans mon fichier d'erreurs.

Si l'abscence d'erreur visuelle était parfaitement normal vu que la directive display_errors était à 0, il aurait bien dû avoir un message d'erreur dans mon fichier.

Or, si le fichier était bien créé, il était désespèrement vide...

J'ai donc commencé à chercher ce qui pouvait bien empêcher PHP d'écrire dans ce fichier, et j'ai tracé l'éxécution de mon script sans trouver le moindre problème.

J'ai ensuite cherché au niveau de ma configuration, sans plus de succés, et du coup, j'ai même envisagé de recompiler le langage, vu que je l'ai compilé un peu à l'arrache du fait que PHP 5.3 n'est toujours pas supporté officiellement par un port de FreeBSD.

Sauf que pour une raison que je ne m'explique pas encore, j'ai eu la brillante idée de faire un df -h avant de faire cette recompilation, ce qui m'a permis de constater que ma partition /var était pleine, et qu'en conséquence, PHP ne pouvait absolument pas y écrire le moindre octet.

Evidement, un peu de ménage plus tard, tout a fonctionné beaucoup mieux et j'ai obtenu le comportement que j'attendais.

Moralité de l'histoire me direz-vous ? Elle est double.

Tout d'abord, si quelque chose n'arrive pas à écrire dans autre chose, il faut mieux commencer par vérifier que cet autre chose dispose de la capacité nécéssaire pour acceuillir de nouvelles informations, plutôt que d'incriminer en premier le quelque chose.

Ensuite, si PHP avait lancé une exception, de type, par exemple, internalException, lorsqu'il s'est rendu compte qu'il ne pouvait pas écrire sur le système de fichier, j'aurais pu l'attraper et faire effectuer à mon code un traitement alternatif, comme par exemple provoquer l'affichage d'un message d'erreur m'informant à la fois du problème dans mon code et du fait que PHP ne parvenait pas à écrire dans mon fichier d'erreur.

PHP devrait donc bien générer des exceptions dans des cas où il ne fait strictement rien.