youp,
 
 
j'utilise trigger_error() à tout va pour gérer toute sorte d'erreur pour pouvoir gérer toutes les "erreurs" au même endroit et pour éviter d'avoir des catch/try partout (en gros, je throw mes "erreurs" là où elles se trouvent et je catch tout dans mon error_handler).
 
Le truc c'est que je fais ça aussi quand ce ne sont pas vraiment des erreurs (genre une connection DB qui ne se fait pas...) : par exemple pour faire une redirection.
 
Par exemple : si je ne trouve pas la page demandée, hop trigger_error('404',E_USER_ERROR) et dans le error_handler, je redirige vers une page par défaut.
 
Question : est-ce mal pas bien de faire ça à part pit-être le fait que ça ne soit pas fait pour (ou si ?).
 
 
 
marchi

Je dirais que c'est mal. Très. Ton error_handler doit être monstrueux.

monstrueux ?
 
Je fais des trigger_error('404 message d\'erreur',E_USER_ERROR)
Après je sépare l'error string en '404' (= type d'erreur) + le reste (= un message d'erreur si je veux être plus spécifique)
et je fais

 
ce qui me permet aussi de changer facilement la manière de gérer telle ou telle "erreur", de l'afficher, de l'écrire dans un fichier, d'envoyer un mail admin...
Je sais pas, ça m'a l'air tellement pratique.  
Tu verrais d'autres problèmes mis à part la monstruosité
 
 
 
edit: En fait, c'est juste que je centralise tout dans le error_handler au lieu de remonter "toutes les erreurs" vers mon script principal
 
Exemple :  
le script principal demande une page à la classe page qui elle-même demande la page à la classe DB_page.
Si la classe DB_page ne trouve pas de résultat, au lieu qu'elle retourne false, puis que la classe page retourne false et que le script principal traite cette erreur, je fais trigger_error('404') et zou.
 
 
 
ps: le php sert aussi à pouvoir n'importe quoi après tout

J'ai bien compris...mais pour moi c'est très très moche, justement, de tout centraliser comme ça.
Tu vas avoir un gros paté de switch pour tout gérer au lieu de tout gérer au cas par cas là où ça doit l'être...
Imagine qu'un jour tu as besoin de faire une requête, mais que finalement si la base de données n'est pas dispo et que ça plante c'est pas si grave, tu peux continuer à afficher la page en loggant l'erreur quelque part...bah tu peux pas, ta classe de DB a balancé un trigger_error qui te sort du déroulement normal de ton prog, tu l'as dans l'os.
Avec une Exception spécifique, ton bout de code qui veut faire la requête peut récupérer l'erreur, la traiter, et continuer comme si de rien n'était.

si je peux reviendre dans mon code

et c'est bien ce que je fais pour les situations que tu cites

Il suffit de mettre un return à la fin du traitement de l'erreur

Donc c'est bien comme si je traitais l'erreur là où elle apparait dans le code, et je peux choisir d'en sortir ou de continuer le déroulement normal, exactement comme

pourquoi ne pas utiliser des exceptions, alors? Tu fais tout pour te rapprocher de leur fonctionnement, sans pour autant le faire vraiment...

pour éviter de devoir remonter les erreurs vers le script qui doit les traiter.

Si j'ai vu l'homme qui a vu l'homme qui a vu l'homme qui a vu l'homme qui a vu l'ours,
je ne dois pas attendre que l'homme qui a vu l'ours dise à l'homme qui a vu l'homme qui a vu l'ours qu'il a vu l'ours, que lui-même le dise à l'homme qui a vu l'homme qui a vu l'homme qui a vu l'ours,  que lui même le dise à l'homme qui a vu l'homme qui a vu l'homme qui a vu l'homme qui a vu l'ours qui va enfin me le dire.

Là je sais directement qu'un homme a vu l'ours et je m'enfuis si je vois l'homme en question courir vers moi comme un dératé

 
M'enfin les exceptions sont là pour ça, enfin.
Une exception elle remonte toute seule jusqu'à ce qu'elle tombe sur un catch qui l'attrape...t'as rien à faire toi-même à part écrire le catch qui va bien au bon endroit...

+1

oui je sais mais c'est pour éviter de devoir me poser des questions.
 
Je peux traiter les erreurs de même type provenant de différents endroits du code de la même façon et sans me poser de questions.
Je balance l'erreur dont je dis qu'elle est d'un certain type et je sais qu'elle va être traitée d'une certaine façon.
 
Avec les catchs, à chaque endroit où je suis susceptible d'attraper une erreur, je vais devoir mettre un switch pour savoir quoi faire en fonction de l'erreur, ce que je trouve moins pratique.
 
Enfin j'ai pas trop l'habitude avec la POO aussi alors peut-être que j'ai mal organisé mon script qui du coup fonctionne (de mon avis perso de nioub) de manière plus pratique comme ça.
 
 
M'enfin ce que tu as l'air de dire c'est que ça reviendrait au pire au même donc à priori, ça ne devrait pas me poser de problème non ?

 
you fail at programming.

m'en fiche je fais du php

Non, c'est pire que ça. Tu est OBLIGE de les traiter de la même façon sans te poser de questions.

Tu n'attrapes que les exceptions qui t'intéressent, pas toutes!!
Ton catch ne catche que le type d'exceptions que tu lui demandes de catcher!

Non, ce que je te dis c'est que tout ce que tu trouves mieux avec ton système, est au mieux aussi bien, au pire nettement moins bien qu'avec des exceptions.

ah non, suffit que je donne un autre "nom" à l'erreur. Je ne regroupe que celle dont je suis certain qu'elle doivent être traitées de la même façon.
au pire, je change le nom de l'erreur là ou je la lance, mais ça reviendrait que d'aller chercher le catch pour cette erreur et d'y modifier le traitement

Ah alors là c'est intéressant, je pensais que le catch attrapait toutes les exceptions lancées dans le try.

En fait ce que je trouve bien, c'est d'avoir la gestion de toutes les erreurs centralisées et de ne pas devoir fouiller le code si je veux changer le traitement d'une erreur précise.

Mais vous avez l'air de trouver ça vraiment crade alors je vais quand même voir ce que ça donnerait si je faisais ça de façon normale

Edit: puis à quoi servent finalement les exceptions si ce n'est de pouvoir regrouper la gestion des erreurs. Sinon on ne ferait que des return false non ?

 
m'enfin il t'est jamais venu à l'idée que tu pourrais avoir un bout de code qui lève une exception et qui serait utilisé à 2 endroits différents dans deux contextes différents?
Tu fais comment pour envoyer deux codes d'erreur, là? Tu dupliques le code? Tu ajoutes un paramètre quelque part?

à vrai dire non

tu aurais un exemple (désolé mais j'apprends )

edit: j'ai bien parfois un traitement d'erreur en fonction de la deuxième partie de mon message d'erreur (donc 1 premier tri suivant le type d'erreur, puis si nécessaire en fonction du reste). Je ne sais pas si c'est de ça que tu veux parler

(et si ce topic est une blague du 1er avril tu mérites le pal )

mmm je dois dire que je n'ai encore jamais rencontré ce cas de figure.  
 
Ou peut-etre si, quand je change de comportement suivant que le site soit en dev ou en prod. Mais là, c'est simplement un switch dans ma fonction PrintError() qui dit quoi faire.
 
Enfin je vois un peu ce que tu veux dire et je vais réfléchier un peu à tout ça
 
 
merci en tout cas pour tes remarques

   
 
 
malheureusement non, je suis juste un vrai neuneu, un vrai de vrai

 
ça peut aussi être un cas où tu veux appeler une autre fonction en cas d'échec, un cas où tu veux que l'exception puisse remonter pour être traitée plus haut dans la pile d'appels, ...

mmm je sais pas. Mais c'est sans doute aussi lié à l'organisation du script.

Aussi (mais j'aurais pit-être dû le préciser directement), je ne dis pas que j'exclus l'utilisation des exceptions "normales". C'est juste que là, pour une série de chose (en tout cas les cas que j'ai rencontré), je trouve que ça marche bien comme ça et que c'est finalement assez pratique à l'usage.

Si je complète au besoin avec des try/catchs et que je n'aurai pas de soucis comme ça, alors je pense que je vais rester comme ça.

Mais je vais quand même y réfléchier fortement au vu de ton "mage-beurk" envers ce système.

Tu n'es pas neuneu J'ai le même point de vue.
 
De part le fonctionnement j'ai pas besoin de m'astreindre à mettre du blabla en plus
 
Si on doit réagir à une erreur je comprends mais si on a pas besoin mais simplement de dire à l'utilisateur qu'il a fait une boulette ou à l'admin que y'a un problème avec la base par exemple, je vois pas l'utilité ultime des exceptions, dit autrement c'est faisable avec des erreurs.
Alors pourquoi se faire chier à polluer le code avec des try/catch de partout qui en plus reviennent au même que générer une erreur puisqu'il faut lever l'exception
Et si c'est un truc non prévu qui a merdé, si le code est bien foutu ça génère une erreur aussi, je vois pas l'apport des exceptions à part m'emmerder à mettre du catch de partout que je m'économise avec les erreur.
 
 
Alors peut être que c'est mieux, sauf que pour le moment j'en voit difficilement l'avantage. Dois je me forcer à utiliser un truc qui m'apporte rien pour l'instant

ouf merci, ça me rassure

Aller un comprimé de try{} matin, un de catch ce midi et tu me prendras un trow à 16h

C'est déprimant.
Tu ne try/catches une exception que si tu veux la traiter dans le bout de code en question, sinon tu la laisses se propager.

Une levée d'exception a un mécanisme équivalent à celui de votre trigger_error, sauf qu'en plus tu peux catcher une exception à différents endroits au lieu d'avoir une grosse fonction qui fait tout au niveau le plus global de ton programme...

Ton trigger_error c'est une levée d'exception dont le bloc try est unique, englobant tout le programme, et le catch est ton error_handler.
Utiliser ce truc par rapport à des exceptions c'est s'imposer soi-même des contraintes, et se priver d'avantages gratuits.

ah je viens de comprendre le "se propage tout seul" (je pensais qu'il fallait faire un try/catch à chaque "niveau" pour remonter l'erreur)

Mais non, suis-je bête et ne sais-je lire ce que tu me disais.

Donc en gros, suffit que je fasse un try/catch au tout début de mon script et c'est bon. J'ai bien compris (finalement) ?

ps: encore desoled, j'suis têtu parfois

Si tu veux faire aussi moche avec les exceptions que sans, oui.

(je vais abandonner ce topic, je crois, sinon je vais finir par déprimer vraiment.)

du coup je me demande.
 
Dans quel cas tu utiliserais les erreurs par trigger_error ?

Aucun?

Jamais. Ca n'a aucun intérêt. C'est du bricolage qui date d'avant l'implémentation des Exceptions dans php.

   
 
 
 
 
ok je vois, du coup faut que je repense tout mon code    *continue de réfléchir...*

oki oki merci de ta patience en tout cas

Juste pour bien comprendre, est-ce correct de faire ça comme ça ?
 

Presque.

Il faut que tu te crées tes propres exceptions héritant d'Exception au lieu d'utiliser la classe générique Exception.
Comme ça tu ne catches que celles dont tu as besoin, et pas besoin de re-lancer une éventuelle exception lancée par $DB->GetDBData();

ça donnerait plutot ça, donc, en gros:
 
 

class B
{
   public function GetData()
   {
       $DB = new DB();
       $DB->GetDBData(); // peut thrower une exception mais qu'on laisse remonter
   
       //fait autre chose
 
       throw new GetDataException('message',code);
   }
}
 
 
 
class A
{
    public function Manger()
    {
        $B = new B();
        try
        {
           $B->GetData();
        }
        catch(GetDataException $e)
        {
           // traitement de l'exception GetData
        }
        catch(XYException $e){
            // traitement de l'exception XY
        }
    }
}
 
 
 
class C
{
    public function Boire()
    {
        $DB = new DB();
        $DB->GetDBData(); // peut thrower une exception qu'on laisse remonter
    }
}

try
{
    $A->Manger();
    $C->Boire(); 
}
catch(DBException $e)
{
    // traitement de l'exception DB
}

PHP n'a pas d'autre exception que Exception en built-in? Genre en Python il y a e.g. ValueError qui existe déjà (et plein d'autres, il y en a presque 2 douzaines), donc pour pas mal d'erreurs génériques pas besoin de se créer ses exceptions

ah oui pas bête
 
Encore une question
 
Comment faire lors de l'attrappage de l'exception, lui dire de retourner là où l'exception a été lancée et de continuer normalement ?

 
non.