Voici une RFC destinée à servir principalement en environnements de développement :

L’idée derrière cette RFC, basée sur la fonction assert(), est de permettre l’exécution de code de débogage, en développement uniquement. Cela permettrait à la fois d’identifier des problèmes (encore une fois, en environnements de développement) et de documenter le code. Plusieurs exemples illustrant les différents cas d’usage sont donnés dans la RFC.

En cas d’échec, la condition spécifiée en premier paramètre de assert() n’étant pas vraie, une exception de type AssertException (soit spécifiée en second paramètre, soit générée automatiquement) sera levée — passer par une exception plutôt qu’une erreur permettant d’obtenir plus facilement une stacktrace.

L’activation ou non des assertions serait paramétrée par le biais d’une directive .ini nommée zend.assertions, qui pourrait valoir :

  • 1 : pour générer et exécuter le code correspondant aux assertions : c’est la valeur qui sera généralement utilisée en environnement de développement
  • 0 : pour générer le code mais ne pas l’exécuter
  • -1 : pour ne pas du tout générer le code de l’assertion (coût nul, à utiliser en production)

L’API proposée par cette RFC est globalement compatible avec celle actuellement en place pour la fonction assert() existante : il s’agit surtout d’améliorer celle-ci, notamment en supprimant complétement la génération et l’exécution du code de l’assertion en mode « production ».

Les votes se sont tenus du 19 au 26 février et nous avons exprimé un avis plutôt négatif sur internals@, considérant principalement que mélanger le code et les tests n’était pas l’approche qui nous semblait la meilleure et ne souhaitant donc pas encourager l’utilisation de assert().
Les résultats ont finalement été les suivants, cette RFC est donc passée :

  • 20 « oui » avec exceptions personnalisées
  • 11 « oui » sans exception personnalisée
  • 1 seul et unique « non »