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

Sondage : Vous êtes partisan de quelle solution? Vous n’avez pas la permission de voter pour ce sondage.
Je préfère utiliser un or die().	10.00%	1	10.00%
Je préfère utiliser les exceptions.	90.00%	9	90.00%
J'utilise l'une ou l'autre, selon les cas.	0%	0	0%
Total		10 vote(s)	100%

* Vous avez voté pour cette proposition.

[Voir les résultats]

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

naholyr
Hors ligne

Membre régulier

Messages : 683
Sujets : 6
Inscription : Aug 2006

#20

05-09-2009, 12:47 PM

(05-09-2009, 02:48 AM)Argorate a écrit : 1. la présentation à l'utilisateur est celle qu'on en fait, rien empêche de le faire dans un joli cadre etc.

Lolilol "or die('<html>............" j'imagine bien tiens :lol:

Citation :2. Comme je l'ai dit, il suffit de créer sa propre fonction gérant d'un coté l'affichage client (1) et de l'autre l'affichage de mysql_error uniquement au dev. (Pas de pb de sécurité donc).

Entre :

Code PHP :
<?php 

function mysqlError($mysql_error) 

{

  // traitement de l'erreur :

  // Affichage d'une page d'erreur non détaillée à l'utilisateur

  // Envoi d'un mail au dév avec $mysql_error

  // Eventuellement traitement de debug_backtrace() pour avoir le détail d'exécution (gare au memory_limit cette fonction est souvent inutilisable...)

}

function main() 

{

  //...

  mysql_query('...') or myFunction(mysql_error());

  //...

}

//index.php

main();

Et :

Code PHP :
<?php 

function mysqlError(Exception $e) 

{

  // traitement de l'erreur :

  // Affichage d'une page d'erreur non détaillée à l'utilisateur

  // Envoi d'un mail au dév avec $e->getMessage()

  // Eventuellement traitement de $e->getTraceAsString() pour avoir le détail d'exécution (aucun pb d'utilisation)

}

function main() 

{

  //...

  mysql_query('...') or throw new SQLException(mysql_error());

  //...

}

//index.php

try

{

  main();

}

catch (SQLException $e)

{

  mysqlError($e);

}

Tu vois une différence notable toi ? Je peux formater mon message correctement aussi bien avec die() qu'avec mon exception. Sauf qu'avec die() je n'ai aucun détail alors qu'avec mes exceptions j'ai :
- la possibilité de les dissocier (par exemple je pourrai lever une exception SQLSyntaxException pour dissocier un problème de construction de requête d'un problème de serveur, et traiter ces cas d'erreur différemment avec des catch distincts).
- une trace d'exécution déjà construite et exploitable très simplement pour les logs.

Citation :3. Une erreur n'a pas a être traité, elle ne doit pas exister: Une erreur SQL ne peut pas exister si la requêtes est bien formuler et que la BDD est a jour et sans problème interne.

Pas trop de problème à trouver des chaussettes à ta taille ? Je suppose que tu es Dieu, je m'incline donc.
Oui parce qu'à part un être omniscient et omnipotent, je ne vois pas qui pourra assurer que toute erreur peut toujours être évité... Même les mecs de la NASA le savent (ils passent une heure à faire des 'check' dans tous les sens avant de lancer la fusée, c'est pas pour faire joli, c'est parce qu'une erreur peut *toujours* se produire, et qu'il vaut mieux la détecter à l'avance plutôt que de croire qu'on pourra la traiter le moment venu).

Citation :4. Grâce a la fonction que l'on crée, rien empêche de faire des log, même si je pense que c'est aux joueurs de venir signaler les bugs qu'ils rencontrent (encore plus en phase de bêta test).

Idem pour les exceptions, la souplesse vue précédemment en plus.

Citation :5. Pas compris.

Il explique que die() provoque *toujours* un affichage. On peut souhaiter que l'affichage ne se produise pas toujours selon l'environnement d'exécution (je fais tourner mon appli en environnement de dév : je veux voir tous les messages, par contre en prod je veux qu'ils soient envoyés dans un fichier). Cela ne peut pas être géré si on utilise die(), alors qu'en bannissant cette fonction soit on maitrise notre output, soit on laisse PHP le faire (avec error_log et display_errors dans le php.ini selon l'environnement).
Mais bon cet argument est effectivement cassé du moment qu'on ne fait pas "or die()" mais "or fonction_perso()".

Citation :6. Je n'ai pas compris ce qu'on doit nettoyer. Mais même s'il y a une tache a faire, si on appel une fonction qui fait ce traitement, je vois pas le pb.

En effet

Citation :Bref, dans toute chose il y a des pours et des contres, reste à savoir ce qui nous convient le mieux.

C'est là que je ne suis pas d'accord :

Code PHP :
<?php 

mysql_query() or die() 

Pour : On est sûr que le traitement s'arrête là.
Contre : On ne maîtrise rien. C'est tout le script qui s'arrête, pas juste la fonction courante.

Code PHP :
<?php 

mysql_query() or fonction() 

Pour : On fait ce qu'on veut dans fonction()
Contre : On n'est pas sûr en lisant ça que fonction() stoppe l'exécution ici, et on n'est pas sûr que le traitement s'arrête là. De plus on ne choisit pas quel traitement faire, c'est fonction() et point-barre.

Code PHP :
<?php 

mysql_query() or throw new SQLException() 

Pour : On est sûr que le traitement en cours (et pas "tout le script") s'arrête là. On spécifie précisément à l'aide de la classe de l'exception quelle erreur a provoqué cet arrêt. On laisse la possibilité au processus parent soit de laisser passer l'exception, soit de la catcher lui-même pour la traiter directement = souplesse ultime.
Contre : Oblige à déclarer une classe "SQLException extends Exception {}" (oh noe, une ligne :'(((((). Oblige à ajouter "try" et "catch ()" dans le processus parent pour (oh noe, 2 lignes :'((((().

En Java l'utilisation des exceptions est *obligatoire*, c'est à dire que tout exception qui n'hérite pas de RuntimeException (qui regroupe toutes les exceptions NullPointer, DivisionByZero, etc... qui peuvent se produire tout le temps) doit être déclarée dans le prototype de la fonction, et toute fonction qui appelle cette dernière devra soit la catcher soit la déclarer elle-même dans son prototype.

Code PHP :
<?php 

void maFonction() throws MonException

{

  if (...) throw new MonException(); // Ceci apparaissant dans le corps de ma fonction, 

  // throws MonException doit apparaitre dans le profil de ma fonction, sinon ça compile pas :)

}

void monAutreFonction()

{

  maFonction(); // Tel quel, ça ne compilera pas :

  // soit je catche MonException ici, 

  // soit je déclare "throws MonException" dans le profil de ma fonction

}

Quelle robustesse cela apporte au code ! Cela change vraiment la vie... Si on n'est pas forcé de souhaiter ça au PHP, on peut au moins admettre l'utilité des exceptions par rapport aux vieilles méthodes d'il y a 10 ans à coup de die()...

Ressources [PHP][MySQL][ [Image: fav.png]

prototype.js]

« Sujet précédent | Sujet suivant »

Utilisateur(s) parcourant ce sujet : 6 visiteur(s)

Messages dans ce sujet

[Débat] "or die" ou "exception" ? - par NicoMSEvent - 02-09-2009, 08:45 AM

JeuWeb Créez votre jeu par navigateur !