[Débat] "or die" ou "exception" ?

[naholyr]

Attention, array_rand() renvoie un index, pas une valeur !

Code PHP :

<?php 

$smilies = array(";-)", ":-P", ":-D", "X)", "T_T");

$smiley = $smilies[array_rand($smilies)]; 

[Sephi-Chan]

Je pourrais bien proposer la version Ruby, bien plus lisible :

[ ";-)", ":-P", ":-D", "X)", "T_T" ].shuffle.first

Mais il s'avère que la classe Array de Ruby propose une méthode built-in (donc plus performante) pour faire ça !

[ ";-)", ":-P", ":-D", "X)", "T_T" ].choice

Sephi-Chan, p'tain c'est chiant d'utiliser un langage qui roxx… iffle:

[NicoMSEvent]

très joliment écrit! (faut absolument que je termine ma béta, et que je m'y mette ^^)

[Ter Rowan]

{troll inside}

un grand philosophe a écrit :

Ce n'est pas parce que c'est court que c'est forcément élégant.
Regardez les minijupes : tout dépend de la taille des cuisses qui les portent !

sinon sans avoir d'idée sur la question (je sais faire des die, les exceptions j'ai l'impression de comprendre même si je n'ai pas encore pratiqué), je n'arrive pas au vu de vos arguments à me faire un avis

donc, comme ça m'intéresse mine de rien, essayez d'autres types d'argument, parce que là ça arrive pas à me convaincre de l'un ou l'autre :'(

[guile]

Wouarf naholyr, bien vu ;-)... il faut avouer que j'ai écrit ce bout de code à la volée, sans m'être documenté sur la fonction array_rand... j'aurais dû :-P

Pour les arguments die ou exceptions... c'est bien simple :
un die() :
hyper simple et rapide à mettre en place , donne un rendu dégueulasse côté client. Pour faire évoluer ce système, faudra se taper chaque die() ...
exception :
Pas facile à comprendre au début, mais de base, ce n'est pas si complexe que ça. Les exceptions peuvent très bien évoluer vers un système super bien foutu
la fonction maison qui fait un bon gros exit() :
Peut être aussi simple qu'un die() pour un rendu similaire, et peut être complexe comme une exception. Ca peut évoluer facilement (une fonction centralise tout), MAIS la complexité sera bien plus grande qu'avec les exceptions, au niveau fonctionnalité similaire.

Résultat : à chacun de voir ce qu'il veut faire.

[Ekilio]

Si je devais donner un seul argument en faveur des exceptions, je dirais : la trace.

Les exceptions permettent, lorsqu'on les attrape, d'avoir la trace de toutes les fonctions qui ont été appellées, une après l'autre, avec leurs arguments, la ligne et le fichier de chacune, etc... jusqu'à savoir très exactement ce qui a causé l'erreur.

A vrai dire je ne vois strictement aucun avantage à or die()... J'ai beau chercher, j'en connais pas. C'est plus long à écrire et à utiliser, on a moins de renseignements, on ne peut pas en faire "ce qu'on veux"...

Un autre intérêt des exceptions est la possibilité d'en gérer plusieurs simplement. Petit exemple en code pour comprendre. Imaginons une situation : nous avons une administration, avec des administrateurs qui ont différents droits. En or die(), ça donnerais à peu près ça : (J'utilise des classes pour simplifier le code)

Code PHP :

<?php



// Connexion de l'utilisateur

$utilisateur = new utilisateur;

$utilisateur->connecter() or die('Login ou mot de passe incorrect');



// Vérification des droits d'accéder à cette partie

$utilisateur->verifierDroits('administration') or die('Droits incorrects');



// Vérification des paramètres passés

$parametres->verifier() or die('Modification impossible');



// Execution de la requête SQL voulue

$db::query('UPDATE machin') or die('Requête impossible à executer');



?>

[QuentinC]

Les exceptions permettent, lorsqu'on les attrape, d'avoir la trace de toutes les fonctions qui ont été appellées, une après l'autre, avec leurs arguments, la ligne et le fichier de chacune, etc... jusqu'à savoir très exactement ce qui a causé l'erreur.

Ceci n'est malheureusement pas vrai : cf. fonction getDebugBacktrace.

[Ekilio]

Les exceptions permettent, lorsqu'on les attrape, d'avoir la trace de toutes les fonctions qui ont été appellées, une après l'autre, avec leurs arguments, la ligne et le fichier de chacune, etc... jusqu'à savoir très exactement ce qui a causé l'erreur.

Ceci n'est malheureusement pas vrai : cf. fonction getDebugBacktrace.

Heu... Je ne trouve pas cette fonction sur le manuel php ^^' Mais je ne vois pas en quoi ce n'est pas vrai ? cf l'exemple que j'ai donné dans le message et qui l'illustre exactement ^^'

Edit : je viens de comprendre : en fait, tu proposes d'utilise debug_backtrace() pour coder une fonction qui récupèrera le contexte d'une erreur, et sa trace ? Donc en gros, de recoder le système d'Exception intégré à php ? Quel intérêt, vu que ce sera fatalement plus lent qu'un truc pré-codé ? ^^'

[naholyr]

L'objet Exception contient une méthode getTrace() et getTraceAsString() qui sont tout autant (voire plus) exploitables que debug_backtrace().

[QuentinC]

L'objet Exception contient une méthode getTrace() et getTraceAsString() qui sont tout autant (voire plus) exploitables que debug_backtrace().

En effet. Mais c'était juste pour signaler qu'avoir un trace complet n'était pas uniquement possible qu'avec les exceptions.