Bonjour, je souhaite pouvoir intercepter toute erreur d'exécution fatale
d'un script ou de l'accès à une base de données (donc une erreur PHP ou une
erreur SQL)
Pour ce qui est des erreurs PHP j'ai copié collé le code de la doc au début
d'un fichier inclus par tous les scripts :
error_reporting(E_ERROR);
function myErrorHandler($errno, $errstr, $errfile, $errline)
{
switch ($errno) {
case E_USER_ERROR:
echo "<b>My ERROR</b> [$errno] $errstr<br />\n";
echo " Fatal error in line $errline of file $errfile";
exit(1);
break;
case E_USER_WARNING:
echo "<b>My WARNING</b> [$errno] $errstr<br />\n";
break;
case E_USER_NOTICE:
echo "<b>My NOTICE</b> [$errno] $errstr<br />\n";
break;
default:
echo "Unkown error type: [$errno] $errstr<br />\n";
break;
}
echo "$errfile:$errline";
}
set_error_handler ('myErrorHandler');
Le problème c'est que j'intercepte les notices (accès à une clé de tableau
inexistante par ex) et absolument pas les erreurs fatales.
Exemple :
Unkown error type: [8] Undefined index: A
/usr/local/www/www_zouplaz_dev/scripts/app/appmodule.php:137
Fatal error: Call to undefined function: numrows() in
/usr/local/www/www_zouplaz_dev/scripts/app/newsmodule.php on line 47
Je ne comprends pas, pourtant la doc indique clairement l'usage de
error_reporting(E_ERROR);
Cette action est irreversible, confirmez la suppression du commentaire ?
Signaler le commentaire
Veuillez sélectionner un problème
Nudité
Violence
Harcèlement
Fraude
Vente illégale
Discours haineux
Terrorisme
Autre
Stephane Pineau
Le 29 Jul 2005 17:10:03 GMT, Zouplaz écrivait:
set_error_handler ('myErrorHandler');
Le problème c'est que j'intercepte les notices (accès à une clé de tableau inexistante par ex) et absolument pas les erreurs fatales. .....
http://fr2.php.net/manual/fr/function.set-error-handler.php " Les types d'erreur suivants ne peuvent pas être gérés avec cette fonction : E_ERROR, E_PARSE, E_CORE_ERROR, E_CORE_WARNING, E_COMPILE_ERROR, E_COMPILE_WARNING ainsi que la plupart des E_STRICT d'un fichier lorsque set_error_handler() est appelé."
Il semble logique que ces types d'erreurs ne puissent être trappée... elles correspondent en général à des erreurs qui avec un langage compilé seraient détectées et interrompraient la création de l'éxécutable lors de la compilation des sources.
Je "suppose" que de la même manière ces erreurs sont déclenchées lorsque PHP charge le fichier et produit le pcode avant son "interprétation" ou exécution réelle. Donc en fait dans la phase correspondant à la compilation/linkage en langage compilé. L'exécution "réelle" n'intevient qu'après cette phase, le gestionnaire d'erreur personnalisé n'est donc pas encore fonctionnel au moment du déclenchement de ce type d'erreurs.
De plus comment un routine personnelle pourrait trapper une erreur de type E_PARSE si l'origine de cette erreur est elle-même dans cette routine:-)
Je ne comprends pas, pourtant la doc indique clairement l'usage de error_reporting(E_ERROR);
Ceci n'a rien à voir... error_reporting(E_ERROR) indique simplement à l'interpréteur php d'afficher ou non un message lorsqu'il rencontre une erreur fatale pendant la phase pré-compilation du fichier .php. Encore une fois à ce niveau de traitement de fichier php, les instructions qu'il contient ne sont pas encore en cours d'exécution.
Le 29 Jul 2005 17:10:03 GMT, Zouplaz <noba@no.inval> écrivait:
set_error_handler ('myErrorHandler');
Le problème c'est que j'intercepte les notices (accès à une clé de tableau
inexistante par ex) et absolument pas les erreurs fatales.
.....
http://fr2.php.net/manual/fr/function.set-error-handler.php
" Les types d'erreur suivants ne peuvent pas être gérés avec cette fonction
: E_ERROR, E_PARSE, E_CORE_ERROR, E_CORE_WARNING, E_COMPILE_ERROR,
E_COMPILE_WARNING ainsi que la plupart des E_STRICT d'un fichier lorsque
set_error_handler() est appelé."
Il semble logique que ces types d'erreurs ne puissent être trappée... elles
correspondent en général à des erreurs qui avec un langage compilé seraient
détectées et interrompraient la création de l'éxécutable lors de la
compilation des sources.
Je "suppose" que de la même manière ces erreurs sont déclenchées lorsque PHP
charge le fichier et produit le pcode avant son "interprétation" ou
exécution réelle. Donc en fait dans la phase correspondant à la
compilation/linkage en langage compilé. L'exécution "réelle" n'intevient
qu'après cette phase, le gestionnaire d'erreur personnalisé n'est donc pas
encore fonctionnel au moment du déclenchement de ce type d'erreurs.
De plus comment un routine personnelle pourrait trapper une erreur de type
E_PARSE si l'origine de cette erreur est elle-même dans cette routine:-)
Je ne comprends pas, pourtant la doc indique clairement l'usage de
error_reporting(E_ERROR);
Ceci n'a rien à voir... error_reporting(E_ERROR) indique simplement à
l'interpréteur php d'afficher ou non un message lorsqu'il rencontre une
erreur fatale pendant la phase pré-compilation du fichier .php. Encore une
fois à ce niveau de traitement de fichier php, les instructions qu'il
contient ne sont pas encore en cours d'exécution.
Le problème c'est que j'intercepte les notices (accès à une clé de tableau inexistante par ex) et absolument pas les erreurs fatales. .....
http://fr2.php.net/manual/fr/function.set-error-handler.php " Les types d'erreur suivants ne peuvent pas être gérés avec cette fonction : E_ERROR, E_PARSE, E_CORE_ERROR, E_CORE_WARNING, E_COMPILE_ERROR, E_COMPILE_WARNING ainsi que la plupart des E_STRICT d'un fichier lorsque set_error_handler() est appelé."
Il semble logique que ces types d'erreurs ne puissent être trappée... elles correspondent en général à des erreurs qui avec un langage compilé seraient détectées et interrompraient la création de l'éxécutable lors de la compilation des sources.
Je "suppose" que de la même manière ces erreurs sont déclenchées lorsque PHP charge le fichier et produit le pcode avant son "interprétation" ou exécution réelle. Donc en fait dans la phase correspondant à la compilation/linkage en langage compilé. L'exécution "réelle" n'intevient qu'après cette phase, le gestionnaire d'erreur personnalisé n'est donc pas encore fonctionnel au moment du déclenchement de ce type d'erreurs.
De plus comment un routine personnelle pourrait trapper une erreur de type E_PARSE si l'origine de cette erreur est elle-même dans cette routine:-)
Je ne comprends pas, pourtant la doc indique clairement l'usage de error_reporting(E_ERROR);
Ceci n'a rien à voir... error_reporting(E_ERROR) indique simplement à l'interpréteur php d'afficher ou non un message lorsqu'il rencontre une erreur fatale pendant la phase pré-compilation du fichier .php. Encore une fois à ce niveau de traitement de fichier php, les instructions qu'il contient ne sont pas encore en cours d'exécution.
http://fr2.php.net/manual/fr/function.set-error-handler.php " Les types d'erreur suivants ne peuvent pas être gérés avec cette fonction : E_ERROR, E_PARSE, E_CORE_ERROR, E_CORE_WARNING, E_COMPILE_ERROR, E_COMPILE_WARNING ainsi que la plupart des E_STRICT d'un fichier lorsque set_error_handler() est appelé."
Bin mince alors, j'ai zappé ces 3 lignes
Il semble logique que ces types d'erreurs ne puissent être trappée... elles correspondent en général à des erreurs qui avec un langage compilé seraient détectées et interrompraient la création de l'éxécutable lors de la compilation des sources.
Concernant les erreurs de type E_PARSE oui, c'est logique mais pour ce qui est des autres ça l'est moins - en tout cas c'est dommage, je suppose que le problème ne se pose plus avec les exceptions sous php5.
Je me suis vraiment persuadé tout seul ;-) Tant pis
Stephane Pineau <spineau@teaser.fr> wrote in
news:3p5le1t6aqjv23cf8boof92cimlnm6qr4p@4ax.com:
http://fr2.php.net/manual/fr/function.set-error-handler.php
" Les types d'erreur suivants ne peuvent pas être gérés avec cette
fonction
: E_ERROR, E_PARSE, E_CORE_ERROR, E_CORE_WARNING, E_COMPILE_ERROR,
E_COMPILE_WARNING ainsi que la plupart des E_STRICT d'un fichier
lorsque set_error_handler() est appelé."
Bin mince alors, j'ai zappé ces 3 lignes
Il semble logique que ces types d'erreurs ne puissent être trappée...
elles correspondent en général à des erreurs qui avec un langage
compilé seraient détectées et interrompraient la création de
l'éxécutable lors de la compilation des sources.
Concernant les erreurs de type E_PARSE oui, c'est logique mais pour ce qui
est des autres ça l'est moins - en tout cas c'est dommage, je suppose que le
problème ne se pose plus avec les exceptions sous php5.
Je me suis vraiment persuadé tout seul ;-) Tant pis
http://fr2.php.net/manual/fr/function.set-error-handler.php " Les types d'erreur suivants ne peuvent pas être gérés avec cette fonction : E_ERROR, E_PARSE, E_CORE_ERROR, E_CORE_WARNING, E_COMPILE_ERROR, E_COMPILE_WARNING ainsi que la plupart des E_STRICT d'un fichier lorsque set_error_handler() est appelé."
Bin mince alors, j'ai zappé ces 3 lignes
Il semble logique que ces types d'erreurs ne puissent être trappée... elles correspondent en général à des erreurs qui avec un langage compilé seraient détectées et interrompraient la création de l'éxécutable lors de la compilation des sources.
Concernant les erreurs de type E_PARSE oui, c'est logique mais pour ce qui est des autres ça l'est moins - en tout cas c'est dommage, je suppose que le problème ne se pose plus avec les exceptions sous php5.
Je me suis vraiment persuadé tout seul ;-) Tant pis
