Valery Fremaux

I have PHP 5 exceptions not working, on a PHP 5.2.3 over Apache 2.0.59, using compatible eAccelerator for PHP 5.

even a simple exception test like this

try {
    echo "test exceptions in try";                 (1)
    $error = 'Always throw this';
    throw new Exception($error);

    // should never be processed.
    echo 'Never go here !!';                        (2)
}
catch(Exception $e) {
    echo "Exception captured: ",  $e->getMessage(), "\n";    (3)
}

// continue
echo 'Hello everybody !';                   (4)

definitely traps with an Uncaught Exception 'Exception' ... message, and does never catch anything. Neither 2,3, nor 4 are printed.

My problem is that the "Global Search Engine" uses part of Zend framework that do extensivelly use exceptions. The global search engine I redesigned for getting it working for Moodle 1.8 may be upset by such a setting, specially for developpers ou have to clone often implementations for testing.

Do someone known about this misconfiguration ? 

Après avoir fouillé ce que j'ai pu sur tous les sites php, je ne trouve toujours pas. Avec mon PHP 5.2.3, impossible de faire fonctionner les exceptions. Je tombe systématiquement sur un message

Uncaught Exception (Exception) blah blah ...

Même pour le code de test simplissime que voilà :

try {
    echo "test des exceptions in try";
    $error = 'Toujours lancer cette erreur';
    throw new Exception($error);

    // le code suivant une exception n'est pas exécuté.
    echo 'Jamais exécuté';
}
catch(Exception $e) {
    echo "Capture de l'exception : ",  $e->getMessage(), "\n";
}

// Continue l'exécution
echo 'Bonjour le Monde !';

Tout se passe comme si le catch était mal reconnu, ou mal traité.

Le hic, c'est que le moteur de recherche qui utilise une partie du framework Zend est bourré de try ... catch, et que le moteur de recherche ne sait donc pas bien se récupérer de situaitons anormales (il fait tout planter).

Quelqu'un à des billes là-dessus ?
 

Tu as raison, c'est une erreur de conception de l'affichage des détails qui mériterait une entrée de faute rubrique "security issue" dans le tracker...

A confirmer...

En effet Etienne, mais on ne peut pas avoir le beurre et l'argent du beurre (la souplesse de combinaison des capacités et la simplicité de dévelppement pour le programmeur).

Réduire des "rôles" à des "presets" simples, cachés derrière un intitulé (identifiant simple) est évidemment plus concis au niveau de la programmation en boût de chaîne, mais évidemment plus rigide.

Nous devons nous faire à l'idée que la programmation de Moodle deviendra probablement de plus en plus compliquée, plus la plate-forme commence à évoluer vers un système "complet" et très "méta-renseigné".

Pour la cohérence, je pense qu'il faut mener une réflexion sur les capacités qu'on réutilise et les nouvelles que l'on crée. Les capacités fournies par le coeur de Moodle (moolde ont eu une origine très précise. Il serait à mon avis erroné de n'en retenir que la "sémantique générale" portée par son nom. "moodle:viewdetails" par exemple, n'est pas une sémantique "générale" de "permettre de voir les détails" dans n'importe quel endroit de la plate forme. Elle doit rester liée à la visualisation des détails du profil de l'utilisateur. Donc on préférera localiser les capacités à son problème, et n'utiliser des capacités "externes" que si on connait parfaitement leur sémantique. 

Cependant, pour parler de cohérence, le problème viendra de ce que tous les développeurs ne connaissent pas "par coeur" (et heureusement pour eux !!) la liste de toutes les capacités du coeur ou apportées par la suite. Et de nombreux développeurs sont tentés ou ont simplement besoin d'informations hors de leur problème propre. Difficile pour eux de savoir si ces informations sont sujettes à capacité ou non. C'est une vérification que l'on DEVRAIT faire en tant que développeur, mais qui reste difficile à assumer.

Je préconise toujours la règle de "solidité" dans ce cas, qui dit que chacun doit essayer, pour autant faire se peut, d'être le plus strict possible dans l' implémentation (le plus Moodle possible en fait) de son propre espace d'information et de rester "souple" avec ce que l'on utilise des modèles des autres. Ceci peut passer par le rapatriement, chez soi, de certaines vérifications ou contrôles que l'on aurait aimé voir pris en charge à l'extérieur.

Probablement que le développeur de ces blocs n'a pas assumé cette relation fonctionnelle (où que le code de la version précédente le faisait autrement et que la migration a produit un effet de bord).

Sur ce, salut Etienne !!

Valéry