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

[QuentinC]

Voici un article d'alsacréations qui peut apporter un peu d'eau au moulin :
Gérer les erreurs MySQL en php sans or die. La qualité de cet article est bien en-deça de ce qu'on y lit habituellement, mais ça peut servir.

Personnellement, j'utilise une sous-classe PDO programmée par mes soins, et donc les exceptions. J'ai même converti les warnings et notices standard en exceptions.
Par contre, paradoxalement, il n'y a pas énormément de try...catch partout dans mon code. Le traitement est centralisé dans une fonction que php se charge d'appeler lui-même quand il rencontre une exception non catchée (cf. set_exception_handler). Une facilité du langage bien pratique, il faut bien l'avouer.

Ce qui me fait venir à un argument supplémentaire à l'encontre de or die que personne n'a encore mentionné.
Rajouter ce fameux or die après à la fin de la ligne, non seulement c'est barbant à écrire ou à coller et recoller, mais en plus c'est vite oublié quand on est pris dans le feu du coding et qu'on a bien en tête ce qu'on a à faire.
Que se passe-t-il s'il y a une erreur à un endroit du script où on a oublié notre or die ? inutile de faire de dessin je pense, vous en avez déjà tous fait l'expérience au moins une fois : c'est la catastrophe, tout se barre en couille. ON peut appeler ça... une erreur dans la gestion des erreurs.

Oui vous me direz, on peu aussi oublier les try...catch. En effet. Le compilateur n'est pas là pour le rappeler, comme c'est le cas par exemple en java (bon par contre en java, devoir catcher toutes les SQLException, pour le coup, c'est vraiment lourd).

Vu que tout est centralisé, je n'ai plus besoin d'écrire à chaque fois un code de gestion d'erreur qui gêne la lisibilité, qui est barbant à écrire et qui peut potentiellement être oublié. Le seul moment où j'ai besoin d'en écrire un, c'est pour un cas spécifique, mais là évidemment on n'y coupe pas quelque soit la méthode (exception ou non), et là généralement un simple if si naturel suffit (un if du genre la requête a-t-elle retourné un enregistrement ?)

Le fait de centraliser toutes les erreurs dans une fonction ne gêne pas du tout qu'on peut faire tout ce qu'on veut spécifiquement selon le cas. C'est une erreur SQL ? On balance une page d'erreur 500. Je suis admin ? On affiche la requête. Je ne suis pad admin ? On log la requête quelque part et on affiche un message générique du genre désolé pour le désagrément.

Voilà.

[Argorate]

Sephi: j'ai déjà dit ce que j'en pensé dans mon premier post

Allwise : les cas où il y a une erreur -ce qui doit être rare pour des requête SQL-, on traite l'erreur même avec un or die(), je ne vois pas le soucis.
Je n'ai jamais parlé en général comme certains semblent le croire, mais bien dans ce cas précis.

naholyr :
Pour ce qui est des erreurs, c'est un raisonnement dans l'idéal, évidemment qu'il n'y a pas 0% d'erreur (ça se saurait^^), le or die() est justement là pour quand ça merde.

Et le fait qu'il affiche tjs qq chose n'est pas une gène, puisqu'il faut justement toujours prévenir l'utilisateur qu'il y a eu une erreur.
Quand a arrêter le script, il me semble que c'est normal, charger une page sans ce qu'il faut dedans ne sert a rien sinon a bouffé des ressources pour affichés au final une page complètement faussé...

Le fait de centraliser toutes les erreurs dans une fonction ne gêne pas du tout qu'on peut faire tout ce qu'on veut spécifiquement selon le cas. C'est une erreur SQL ? On balance une page d'erreur 500. Je suis admin ? On affiche la requête. Je ne suis pad admin ? On log la requête quelque part et on affiche un message générique du genre désolé pour le désagrément.

C'est Bien ce que je fais, soit je préviens l'utilisateur, quitte a faire un log s'il faut et si on est admin, on peut afficher l'erreur sql en question...

[Zamentur]

Je trouve que toute les solutions ne sont pas représentées, on peut notamment lancer une erreur avec trigger_error() et avoir définit set_error_handler() afin de gérer tout ceci.

Le tout eventuellement avec une classe de gestion d'erreur

Ceci dit on peux aussi capturer les exceptions avec set_exception_handler() donc il n'est nul besoin de faire un try catch autour d'une fonction main comme vu tout à l'heure.


Pour ma part ce qui me gène ce sont justement les try catch je trouve que çà prend de la place bien souvent.

Ceci étant dit j'ai pas encore cherché spécifiquement à utiliser les exceptions à leur max, donc je ne fais que réagir à ce que je lis, et en globalité, çà parle plus des désavantages du die par rapport aux autres solutions que des avantages des exceptions.

[QuentinC]

Effectivement, on n'a jusqu'à présent pas beaucoup cité d'avantage pour les exceptions. En voici un auquel je pense juste maintenant : avec l'ancien système de gestion d'erreur, on ne peut passer qu'une string qui est juste destinée à être affichée et/ou loggée, alors qu'avec les exceptions on peut utiliser des objets qui contiennent plus d'information.

Autre exemple utile : on voudrait afficher un message différent selon qu'on est admin ou non. L'admin voit le message d'erreur exact, mais en même temps on voudrait que l'utilisateur lambda n'ait pas un message d'excuses générique sans pour autant avoir le message d'erreur exact qui révèlerait trop d'informations. Avec le système traditionnel set_error_handler + trigger_error, désolé mais je ne vois pas comment faire ça efficacement et proprement alors qu'en utilisant la POO c'est assez trivial.

[Zamentur]

Ben si c'est possible à faire il suffit de convertir le message d'erreur en message utilisateur, un simple array pourrait presque faire l'affaire.

Ceci étant dit je comprend que çà pose problème.

Pour le passage d'information +1

[Sephi-Chan]

C'est globalement ce que tu vas faire en gérant les exceptions. Tu peux gérer différemment chaque type comme bon te semble.

Par exemple, avec le code qui suit, je gère les exceptions pour toute mon application puisque tous mes contrôleurs héritent (directement ou non) de ApplicationController. Bien sûr, si à un endroit je veux une gestion différente, j'ai juste à surcharger la méthode à qui je délègue la gestion (ici handle_record_not_found et handle_record_not_saved) à cet endroit spécifique.

class ApplicationController < ActionController::Base

 

  rescue_from ActiveRecord::RecordNotFound, :with => :handle_record_not_found

  rescue_from ActiveRecord::RecordNotSaved, :with => :handle_record_not_saved

  

 

  protected

 

  def handle_record_not_found

    # Cette méthode gère les exceptions ActiveRecord::RecordNotFound.

  end

  

  def handle_record_not_saved

    # Cette méthode gère les exceptions ActiveRecord::RecordNotSaved.

  end

 

end

Enfin bref, le or die() c'est marrant pendant le développement, en dehors de ça, ça n'a aucun intérêt par rapport aux exceptions.


Sephi-Chan

[QuentinC]

Ben si c'est possible à faire il suffit de convertir le message d'erreur en message utilisateur, un simple array pourrait presque faire l'affaire.

Oui, bon, explode, évidemment. Mais c'est pas aussi pratique que deux méthodes séparées.

[guile]

Autre débat. Pour ou contre les fautes d'orthographes dans les die() ?

Exemple :

die('ACCES REFUSER ! Vous n\'avez rien a faire ici. ');

[Sephi-Chan]

Là aussi les exceptions sont mieux : elles corrigent automatiquement les fautes !!
J'veux pas dire mais… Avec des guillemets doubles, tu aurais pas eu besoin d'échapper ton apostrophe, ça aurait été plus lisible.


Sephi-Chan, iffle:

[guile]

Excuse-moi, je la refais :

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

die("ACCES REFUSER! Vous n'avez rien a faire ici. $smiley");