utilisation d'assertions pour la vérification de type en PHP?

Question

Je vérifie les arguments de mes classes en php en utilisant des fonctions de lancement d'exception. J'ai des fonctions qui font un contrôle de base (===, in_array etc) et jettent une exception sur false. Je peux donc faire assertNumeric($argument, "\$argument is not numeric."); au lieu de

if (! is_numeric($argument)) { 
    throw new Exception("\$argument is not numeric."); 
} 

Enregistre quelques frappes

Je lisais dans les commentaires des php manual page on assert() que

Comme indiqué sur Wikipédia - « assertions sont avant tout un outil de développement , ils sont souvent désactivés quand un programme est publié au public . " . Et « Assertions devraient être utilisés pour documenter situations et découvrir errors- programmation logiquement impossible si le « impossible » se produit, alors quelque chose est manifestement erronée fondamentale Ceci est distinct de la gestion des erreurs: la plupart des conditions d'erreur sont possibles, . bien que certains puissent être extrêmement peu susceptibles de se produire dans la pratique utilisant affirmations comme une erreur d'usage général mécanisme de manipulation est généralement peu judicieux: affirmations ne permettent pas la récupération gracieuse d'erreurs, et une défaillance affirmation arrêtera souvent programme execu brusquement. Assertions aussi ne pas afficher une erreur conviviale un message . »

Cela signifie que les conseils donnés par « gk à proliberty dot com » pour forcer affirmations à activer, même si ils ont été désactivés manuellement , GOES aux meilleures pratiques de l'utilisation que eux comme un outil de développement

Alors, suis je le fais mal? »Quels sont les autres/meilleures façons de le faire sont là

?

Answer 1

Personnellement, j'appuie le contenu de Wikipedia et n'utilise pas d'assertions pour la vérification régulière de type. Au lieu de cela, j'utiliserais PHP Type-Hinting (travailler actuellement sur des objets comme php 5.1 et des tableaux depuis php 5.2 ... ne vous aidera pas avec les types de données de base, mais c'est toujours mieux que rien); vous pouvez ensuite utiliser les fonctions que vous avez suggérées ou même aller un peu plus loin et considérer le patch d'Ilia Alshanetsky pour les indices de type généraux. See here.

Answer 2

Comme avec les assertions régulières, vous devriez pouvoir transformer vos assertions personnalisées off via une constante globale pratique ou une méthode de constructeur de variable ou de classe. Ils n'appartiennent vraiment pas (actif) au code de production, ou sont actifs par défaut dans n'importe quel type de bibliothèque. Pour ce que vous les utilisez, cela semble être un gaspillage de cycles de CPU même si vous pouvez les désactiver.

Dans les langages de bas niveau, les assertions sont très utiles pour intercepter des situations très étranges telles que des bogues créés par des optimisations de compilateur spécifiques à une architecture trop zélée. Par exemple, vous savez que dans tout univers sain, la condition affirmée va être vraie. Ensuite, votre compilateur déchire le tissu de l'espace-temps et tout change. Donc, peut-être qu'ils seraient utiles si vous utilisiez quelque chose comme PHC ou Roadsend pour compiler votre application.

J'ai aussi vu un code 'trop sécurisé' (principalement en C) où l'entrée de chaque fonction est gardée par des affirmations. Je vraiment question de la sagesse de le faire.

En bref, vous voulez votre code pour échouer gracieusement ou pas du tout, pas seulement arrêter, surtout si cela dépend de l'entrée de l'utilisateur. Les assertions ne signalent que les conditions qui ont la valeur false, elles ne traitent pas les erreurs .