Reprise du message précédent :

 
non.

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
}

   
 
 
edit: décidément, j'arrive pas à synchro mes posts avec les votres

 
ça se fait pas, ça. D'ailleurs ça n'a pas de sens, si tu peux récupérer localement le problème, je vois pas pourquoi tu lancerais une exception!

C'est pas fait pour.

Et ça n'a pas de sens, une exception c'est pour dire qu'il y a une condition suffisament exceptionnelle pour ne pas être rattrapable localement

edit: bordel skeye

ah tu voulais dire autre chose par là alors ?
 

 
 
En fait, ça pourrait être pratique pour logger l'erreur non ?  
et aussi pour changer le comportement de l'erreur suivant les situations ?
 
 
edit : finalement il y a bien un "avantage" au trigger_error

wat? En quoi "ça pourrait être pratique pour logger l'erreur"? Et idem, ça veut dire quoi "changer le comportement de l'erreur suivant les situations", et en quoi c'est pas faisable avec des exceptions?

 
Bah...oui.
Je voulais dire que par exemple dans le bout de code plus haut A peut manger() même si B.getData() a échoué lamentablement.
Et ce de manière transparente pour le programme principal.
 

 
Le système de log est indépendant de la gestion d'erreurs, tu peux vouloir logger autre chose que des erreurs...
Pour la deuxième question j'ai pas compris ce que tu voulais dire.

non, non et non.

Si j'ai un module dans mon site qui ne veut pas se charger, pour moi c'est une erreur alors je lance une exception pour dire de logger l'erreur - ou d'afficher un message d'erreur suivant que je sois en prod ou pas (mais c'est pit-etre là que je fais mal les choses).
Après, comme après tout, ce n'est pas grave que le module ne s'affiche pas, je continue d'afficher le reste.
Sauf que je ne peux pas (ou pas directement) le faire avec les exceptions (si j'ai bien comprite).

 
bien sûr que si!

 
mais vous venez de dire que non

Ben si, suffit de mettre le try/catch juste autour de ton import de module

Genre (en python)

# om nom nom
try:
    import fail_module
except ImportError, e:
    logging.warning("Epic fail import", e)
# et on continue comme si de rien n'était

Pas du tout, mais tu poses pas les bonnes questions

c'est toi qui comprends mal ce qu'on te dit
La façon de faire est légèrement différente, c'est tout. Tiens, du code pour ton exemple :

class Module{
    
    function __construct($id){
        if($id == 'totoz'){
            throw new Exception('oklol');
        }
    }
}
 
 
$moduleIds = array('totoz', 'dawa', 'pingouino');
$modules = array();
foreach($moduleIds as $id){
    try{
        $modules[] = new Module($id);
    }
    catch(Exception $e){
        error_log($e.getMessage());
    }
}

ok ça a fait tilt

Je pensais que du coup, je ne pourrai plus centraliser la gestion de mes erreurs, mais en fait, comme je fais des classes pour les erreurs, c'est toujours "centralisé", et mieux, avec l'héritage, je peux mieux regrouper les types d'erreurs itou

Enfin bref, j'ai mis le temps, mais je pense commencer à saisir le truc

Merci BEAUCOUP

Skeye, ta patience est  -ifiante  

 
Je trouve, aussi.

Et bah moi je saisis toujours pas

mais awèteuh  chaque fois que je re-y-réfléchis, je change d'avis  
 
Là, maintenant, tout de suite (non je n'ai pas de valise), je me dis que finalement, tout ça c'est quand même un peu se compliquer la tâche pour faire un truc qui se fait tout facilement et qui correspond bien à mon utilisation.
 
Alors je pense avoir compris la "philosophie" du truc, et j'ai compris comment l'utiliser pour que ça réagisse comme j'en ai besoin...  sauf que là, sans rien faire de particulier, ça fait déjà tout ce que je demande. Alors est-ce vraiment utile de s'embêter juste pour que ce soit fait "dans les règles" ?
 
 
 
Enfin bon, je crois qu'on va tourner en rond là (et diviser par zéro si on continue trop longtemps)

 
Ne serait-ce que parce-que tu ne vas pas éternellement développer en php 4 et demi, oui.
Et tu tomberas fatalement un jour sur un cas dans lequel ça te sera utile.
 

 
Bah toi t'es irrécupérable.
Regarde les bouts de code d'exemple postés.

CE que je vois pas c'est qui/quoi récupère l'exception si tu la catches pas là où elle est levée
 
Du coup dans les exemples j'ai l'impression que ça vient de nul part, que je pourrais pas définir une erreur si un fichier n'existe pas, puis 2 lignes plus bas si le champ X du formulaire a mal été rempli...
 
C'est dans ce sens où j'ai du mal à voir avec vos exemples
 
Je comprends aussi la philosophie du truc, mais j'avoue qu'avec une fonction maison de gestion d'erreur je vois pas pour l'instant le plus appliqué à ce que je fais à savoir stopper ou non le script et afficher une erreur pour l'utilisateur.
 
J'expérimenterais quand j'aurais du temps je dois avoir mal saisis un truc tout bête

Un try/catch qui est plus bas dans la stack d'exécution des fonctions
 
Et si t'as aucun handler dans ta stack, PHP a un handler par défaut qui génère une erreur fatale.

Rien compris
 

Apparement non
 
http://docs.python.org/tut/node10.html

je demande l'entrée au panthéon de ce topic epic sur les exceptions PHP.. tres instructif, bien expliqué.. gg skeye en particulier
 
Bref j'lais mis dans mes favoris pour quand je voudrais créer mes propres classes d'exceptions ( ca va venir )