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

[NicoMSEvent]

1ere solution

Code :

mysql_query($Query) or die (mysql_error());

2eme solution

Code :

try{
    $db=mysql_query($request,$link_db);
}
catch(Exception $e){
    echo $e->getMessage();
    throw new Exception(mysql_error());
}

La 1ere solution arrête le script en cas d'erreur de la requete.
La 2eme solution permet au script de continuer, même en cas d'erreur (avec d'autres actions pour les erreurs, par exemple générer un log, envoyer un e-mail a l'administrateur, ...)

Vous vous servez de quoi, et surtout que préférez vous?

[Sephi-Chan]

Je trouve les deux dangereuses. Un site en production ne doit pas afficher ce genre de message et visiblement, le comportement est le même qu'importe l'environnement (développement, production, test).

Toutefois, si je me retrouvais à faire ça, je préférerais une solution basée sur les exceptions.


Sephi-Chan

[NicoMSEvent]

il est possible de ne pas afficher le mysql_error() dans les deux cas... tout est une question de choix (et d'appel de fonction dans les paramètres )

Mais toi, que fais-tu alors?
Pourrais-tu nous mettre un petit exemple? (même en ruby si tu veux :p)

[Allwise]

Les deux n'ont pas le même rôle. Comme tu dis, die() arrête le script, la gestion des exceptions permet de continuer malgré une erreur. Donc tout dépend de l'erreur, de sa criticité, de si elle est bloquante pour la suite des événements ou non.

Les die sont souvent utilisés pour empêcher l'accès à des pages si une condition n'est pas remplie... Par exemple, des pages qui ne devraient pas être appelées directement via l'url, mais plutôt via d'autres scripts.

Les exceptions sont généralement utilisées pour avoir des détails sur la nature de l'erreur. Elles peuvent être utiles aussi si on souhaite donner une autre sortie à un script que l'affichage d'une erreur fatale ou autre.

[My Hotel]

Personnellement, je me sers des exceptions, avec une fonction/classe qui gère différemment l'erreur selon l'environnement où on se trouve, la configuration que l'on a faite, etc...
Au pire, je peux aussi arrêter le script si l'erreur est bloquante pour la suite, ou continuer si c'est pas bien grave.

Voilà

[Sephi-Chan]

Mais toi, que fais-tu alors?
Pourrais-tu nous mettre un petit exemple? (même en ruby si tu veux :p)

ActiveRecord s'occupe de jeter les exceptions qui vont bien. Après, plusieurs façon de les gérer :

Les gérer à la main, je trouve ça lourd est fastidieux.

class UsersController < PublicController



  # On arrive sur cette action via l'URL /users/:id

  def show

    begin

      # Cherche l'utilisateur avec l'id donné.

      # Quand find ne trouve pas d'enregistrement, il lance

      # une exception ActiveRecord::RecordNotFound.

      @user = User.find(params[:id])

    rescue ActiveRecord::RecordNotFound

      # Gestion de l'exception.

    end

  end

  

end

Ne pas envoyer d'exception, les finders dynamiques sont des trucs qui permettent de faire des requêtes genre User.find_by_first_name_and_last_name("Romain", "Tribes"). Ça renvoie un enregistrement (le premier trouvé) ou nil

class UsersController < PublicController



  # On arrive sur cette action via l'URL /users/:id

  def show

    # Cherche l'utilisateur avec l'id donné.

    # Ici, le finder dynamique retourne nil

    # s'il ne trouve rien.

    @user = User.find_by_id(params[:id])

    

    # Ou :

    @user = User.first(:conditions => { :id => params[:id] })

  end

  

end

Ou encore, la solution que j'ai adopté :

class UsersController < PublicController



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



  # On arrive sur cette action via l'URL /users/:id

  def show

    @user = User.find(params[:id])

  end

  

  

  protected

  

  def handle_record_not_found

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

  end

  

end

Je fais ça parce que à partir du moment où l'utilisateur a un ActiveRecord::RecordNotFound, c'est de sa faute. Donc je rend une page lui expliquant son erreur (après avoir envoyé un petit mail qui dit que telle personne fait des trucs louches ) ou le redirige directement ailleurs.


Sephi-Chan

[NicoMSEvent]

ha oui, c'est clairement différent de ce à quoi je m'attendais

mon prochain projet, je le lancerai en ruby, c'est décidé (ou alors je traduit celui-ci en cours, pour la V2 en ruby? )

[guile]

J'avais vu un article sur "or die() must die".

Il est clair qu'un arrêt de script est mal en production, sauf peut être dans les cas extrêmes (les mecs qui tentent de faire des trucs contournés) : dans ce cas, à comportement anormale, réponse anormale.

Pour moi, en dev, en test, les erreurs sont affichées dans la page. En prod, elles sont communiquées aux admins de façon silencieuse, et tous les scripts doivent pouvoir tourner en cas d'erreur : ces scripts ne donnent donc plus grand chose d'utilisable, mais ils sont là.
Pour tout ça, l'utilisation propre d'exceptions est bien.

[Argorate]

Je pense qu'il suffit de créer une fonction qui ne donne le mysql_error() que si on est admin par exemple, et dans un autre cas, juste qu'une erreur c'est produite.

Personnellement, je préfère le die() car une erreur = arrêt et c'est très bien, car continuer le script avec une erreur de ce genre serait plutôt aberrant. De plus ça "m'oblige" a le réparer tout de suite.

Sans parler du problème que le try catch te prend beaucoup de ligne pour par grande chose, alors que le or die se met à la suite...

Bref autant de raison qui me font voter DIE.

[wild-D]

aujourd'hui exception sans hésiter (ça m'a prit du temps pour que je passe complètement le pas).
par contre j'utiliserais pas ta solution telle quelle (je pense aussi que c'est indispensable d'avoir un filtre/tri des messages et infos à afficher selon l'environnement, etc...)

Les exception, ça permet d'avoir une gestion bcp plus fine; et surtout ça permet de modifier le comportement de gestion des erreurs sans avoir automatiquement à aller remettre les main dans le cambouis; de switcher plus facilement facilement entre mode prod/dev et de mélanger au minimum ton code applicatif avec le code de gestion des erreurs/debugage/etc. (enfin pragmatiquement, on pourrait le faire à la mimine, mais puisque les exception offre une interface native autant l'exploiter)

pour moi le but d'une exception est d'arrêter le script proprement (nettoyage et autre rollback, sans oublier éventuel log) à l'inverse d'un die() qui tout seul fait qu'arrêter brutalement le script.