Comment gérer les erreurs PHP ?

Bonjour,

Le titre de ma question n'est peut-être pas très clair.

Voila :

J'aimerais pouvoir en php, dans une fonction, lorsque particulièrement elle renvoie des informations à afficher, lui dire de renvoyer une certaine information par défaut si le script rencontre n'importe quel type d'erreur.

Mon souci est d'éviter que la fonction affiche un message d'erreur qui serait du plus mauvais effet chez le visiteur.

Ce que je veux faire est dans l'esprit de la fameuse erreur 404. Il vaut mieux dans ce cas-là prévoir et afficher une page sympa au lieu du vilain "Not Found"...

Mais dans le problème que je pose, je voudrais récupérer "proprement" l'erreur et faire une certaine action par défaut, si par exemple la fonction doit travailler avec une donnée de la bdd qui se trouve manquante ou erronée.

J'entends souvent parler d'"exceptions" (en parlant d'erreurs) et d'une certaine fonction nommée catch()... Est-ce fait pour le problème que je pose ? Si oui, comment ça marche ? Sinon comment faire pour "attraper" ou "catcher" au vol toutes les erreurs et les gérer proprement ?

Merci d'avance.
Modifié par somdina (03 Dec 2010 - 16:13)

Allo

Pas nécessairement « du plus mauvais effet ».
Gérer les erreurs en PHP restera toujours accèssible : voire même afficher une page d'erreur perso.

Mais ne dit jamais « du plus mauvais effet ». Les pages d'erreurs sont des indicateurs.
Personnellement je préfère aboutir à une page d'erreur plutôt que de ne pas aboutir du tout.

Tu peut personnalisé ta page d'erreur. C'est d'ailleurs un sujet d'intérêt.

Il devrait avoir un article et ou un tuto sur le sujet . . . sur Alsa
Gérer les pages d'erreurs ? En enseignement ? c'est une bible. ah! ah!

++
Modifié par zardoz (03 Dec 2010 - 16:39)

Bonjour,

déjà, tu es sensé désactiver les rapports d'erreurs qui s'affichent à l'écran lorsque tu met ton site en production.

Pour les exceptions try catch throw, il faut les voir comme des messages de débug personnalisés pas comme une info à présenter à l'utilisateur. En gros c'est pour t'aider toi à débugger ton code.

Normalement, tes scripts ne devraient pas provoquer de telles erreurs (même si personne n'est parfait).

Sinon, tu pourrais donner un exemple plus précis d'erreur?
Modifié par bzh (03 Dec 2010 - 16:58)

Hello

Je n'ai pas l'adresse mais j'ai déjà lu un article sur les pages d'erreurs perso sur sympatico.ca
Il s'agissait du « top ten ». Si je le retrouve je le pointe sur Alsa.

Tout ça pour dire qu'une page d'erreur perso : c'est quand même important.
Le 404 se pointe une fois de temps en temps non ? ça vaut le perso.

++

Avec php, il est possible de tester si une connexion à la base de données s'est bien faite, si les résultats ne sont pas vide, etc... Si besoin, il faut vérifier ces différentes choses dans ton programme et traiter l'erreur (en affichant un message + parfois en envoyant un entête http), pas attendre que php lance une erreur et tenter de faire quelque chose avec.

Par exemple mysql_connect va renvoyer false en cas d'erreur :

$link = mysql_connect('127.0.0.1:3307', 'mysql_user', 'mysql_password');
if (!$link) {
    // On fait autre chose
}

Donc tester et faire des script robustes capables de pallier aux erreurs.

Merci pour vos réponses.

Je voulais éviter que ce genre de message "effrayant" s'affiche dans le navigateur de l'utilisateur, pour cause d'erreur dans le programme :

Array ( [0] => 42000 [1] => 1064 [2] => You have an error in your SQL syntax; check the manual that corresponds to your MySQL server version for the right syntax to use near '' . tab_fr_fichiers . ' WHERE code_structure REGEXP '^[1-7]\.[0-9]+$' ORDER BY c' at line 1 ) 1

Avouons que ça fait vraiment mauvais effet pour un visiteur de tomber sur des messages de ce genre, du parfait chinois ! C'est tout juste si moi-même j'y comprends quelque chose à cette affaire d'Array ([0] => 42000 ... A côté, le "Not Found" n'est rien du tout...

Après tout, ce genre de messages ne concernent pas l'utilisateur mais moi. Et encore ici il s'agit d'une erreur de syntaxe, donc de programmation, et non pas d'une erreur de fonctionnement, c'est-à-dire le programme qui bute sur une situation dans son fonctionnement normal, qui conduit à un "FATAL ERROR" par exemple...

L'expérience prouve qu'on peut tout à fait voir signalées par PHP des erreurs de syntaxe, de parse error ou de variables ou index manquants, alors que la vraie erreur se trouve ailleurs, et est d'une toute autre nature. Je ne dis pas que c'est le cas ici, mais ça arrive. D'où l'idée, une fois que le maximum est fait pour prévenir des erreurs (test des données vides, non définies, etc.) on veuille pouvoir attraper l'imprévu et éviter à l'utilisateur de tomber sur un charabia de ce genre, pour son plus grand plaisir je suppose, et la bonne impression qu'il peut avoir sur le concepteur du site qui ne lui a pas épargné ce petit cours d'informatique sur les Array et autres SQL...

Dans le langage BASIC de mon adolescence, j'utilisais une certaine instruction du genre "ON ERROR GOTO", qui permettait de retomber un peu sur ses pattes, d'aiguillonner la suite du programme suivant le type d'erreur :

IF ERROR NUMBER = 23, Faire Ceci...
IF ERROR NUMBER = 55, Faire Cela...
etc.

Cela permettait à la fois de connaître le type d'erreur, mais surtout d'éviter d'afficher une page complètement plantée.

C'était juste pour savoir s'il existait quelque chose de ce genre en PHP. Tout bien réfléchi, PHP n'est pas un langage côté client mais un langage en amont, un langage serveur, qui génère juste la page et l'envoie au navigateur. Cela change beaucoup de choses dans sa philosophie. C'est ce que les débutants comme moi en PHP, habitués à d'autres langages (BASIC, Visual BASIC entre autres, et même simplement le (X)HTML), ont souvent tendance à oublier.

Je me surprends par exemple à vouloir attendre de PHP qu'il arrête son exécution, que j'entre une information à l'écran (du genre avec INPUT) et qu'il poursuive son exécution en fonction de l'entrée, comme avec un formulaire... Or de par sa nature même de langage serveur qui génère simplement un autre code (en l'occurrence le HTML) ça n'a pas de sens qu'il s'arrête en plein milieu de génération d'une page...

Comme l'a dit l'un de vous, en fait finalement, le seul vrai remède est de faire un code robuste qui se plante le moins possible, même si nul n'est parfait...

Bon ben, on fera avec...
Modifié par somdina (04 Dec 2010 - 03:30)

somdina a écrit :

Je me surprends par exemple à vouloir attendre de PHP qu'il arrête son exécution, que j'entre une information à l'écran (du genre avec INPUT) et qu'il poursuive son exécution en fonction de l'entrée, comme avec un formulaire... Or de par sa nature même de langage serveur qui génère simplement un autre code (en l'occurrence le HTML) ça n'a pas de sens qu'il s'arrête en plein milieu de génération d'une page...

En effet, de par la nature du web, il faut essayer de toujours fournir quelque chose à l'utilisateur.