intercepter proprement les fatales erreurs.

Le 20/10/2011 11:28, Etienne a écrit :

Salut

Je traite des données que j'insère dans une base de données,
parfois la donnée que j'insère le génère une fatal erreur lors de
l'ecriture dans la base de données.

PHP Fatal error: INSERT INTO ...

Au final le script s'arrète.
Je souhaite traiter proprement cette erreur. mais je ne peut pas car le
script s'interrompt...

Etienne

Suggesion :

C'est une erreur PHP, pas une erreur MySQL.

Faut voir le code. ;)

Bien amicalement.

Jean François Ortolo

Le 20. 10. 11 11:46, Jean Francois Ortolo a écrit :

Le 20/10/2011 11:28, Etienne a écrit :

PHP Fatal error: INSERT INTO ...

Au final le script s'arrète.
Je souhaite traiter proprement cette erreur. mais je ne peut pas car le
script s'interrompt...

Suggesion :

C'est une erreur PHP, pas une erreur MySQL.

Oui, Jean Francois a raison, c'est surement une erreur php (genre une
chaine sans guillemets, ou autre).

Sinon, pour intercepter les erreurs, tu peux voir à :
http://php.net/manual/fr/language.exceptions.php

franssoa

Le 20/10/2011 11:56, franssoa a écrit :

Sinon, pour intercepter les erreurs, tu peux voir à :
http://php.net/manual/fr/language.exceptions.php

franssoa

Quel est l'intérêt de try catch par rapport à un trigger_error utilisé
avec set_error_handler.
J'utilise la 2nd technique, et on m'a dit que c'était puant (ici même il
me semble) sans trop d'explications - le développeur considère toujours
que ce qu'il a appris n'est qu'axiome et que toute autre proposition est
forcément erronée, donc la discussion constructive est rarement possible -)

On 21/10/11 10:01, Olivier Masson wrote:

Quel est l'intérêt de try catch par rapport à un trigger_error utilisé
avec set_error_handler.

Si tu me permets, la question est maladroite. trigger_error est
plutôt l'équivalent de throw, et set_error_handler l'équivalent du try
catch.

J'utilise la 2nd technique, et on m'a dit que c'était puant (ici même il
me semble) sans trop d'explications - le développeur considère toujours
que ce qu'il a appris n'est qu'axiome et que toute autre proposition est
forcément erronée, donc la discussion constructive est rarement possible -)

Oh non, ici c'est clairement une question de préférence, et l'usage
de l'une ou l'autre technique, voir la combinaison des deux, est une
affaire de goût.

Historiquement, puisque PHP est un langage procédural, il n'y avait
pas de notion d'exception comme il y en a dans les langages orientés
objet. Donc il y a le mécanisme d'enregistrement des erreurs avec
trigger_error. C'est le système qui est intégré à PHP de base, et qui
est donc la voie naturelle de traitement des erreurs. Et vu que les
mécanismes d'erreur de base sont basés dessus, il est incontournable.

Les exceptions sont venues avec l'intégrations des fonctionnalités
orientées objet dont elles font partie. Et ce, sans s'y substituer. Le
mécanisme d'exception a deux avantages sur la gestion par le système
d'erreurs natif :

- la gestion de l'erreur peut être plus facilement déléguée, elle n'a
pas besoin d'être gérée immédiatement
- l'exception peut comporter une charge sémantique qui va faciliter
le traitement de l'erreur (si l'exception est une erreur)

Personnellement je préfère les exceptions, car on peut déléguer la
gestion d'erreur à un niveau d'abstraction supérieur, qui va décider de
ce qu'il faut faire.

Le 22/10/2011 03:59, Mickaël Wolff a écrit :

On 21/10/11 10:01, Olivier Masson wrote:

Personnellement je préfère les exceptions, car on peut déléguer la
gestion d'erreur à un niveau d'abstraction supérieur, qui va décider de
ce qu'il faut faire.

Quelle différence avec trigger_error/set_error_handler ?

C'est vraiment confus pour moi. D'autant plus que dans la doc PHP, ils
utilisent en exemple set_error_handler pour transformer les erreurs en
exceptions.

On 24/10/11 11:26, Olivier Masson wrote:

Quelle différence avec trigger_error/set_error_handler ?

J'aurais dû mal à faire plus clair que l'explication que j'ai donné.

C'est vraiment confus pour moi. D'autant plus que dans la doc PHP, ils
utilisent en exemple set_error_handler pour transformer les erreurs en
exceptions.

Les exceptions ne sont pas le mécanisme de gestion d'erreurs
historique. Donc, si on veut un système de gestion unifié des erreurs en
utilisant les exceptions, il faut lever des exceptions depuis le handler
d'erreur personnalisé. D'où la recette donnée dans la documentation.

Je suis de ceux qui considèrent le mécanisme historique de gestion
des erreurs comme n'étant pas pratique par rapport à l'usage des exceptions.


class my_file_with_exception
[
function open()
{
// tentative
// on a une erreur:
throw new my_file_exception('Permission') ;
}
}

class my_file_exception extends exception { }

class my_file_classic
[
function open()
{
// tentative
// on a une erreur:
trigger_error('Permission') ;
return false ;
}
}

$f = new my_file_exception;
try
{
$f->open();
}
catch (my_file_exception $e)
{
// on peut gérer l'erreur facilement
}

$f = new my_file_classic;
$f->open();
// S'il y a eu une erreur, on ne peut pas la traiter facilement sans
// utiliser de variable globale, ou en faisant gérer l'erreur par la
// classe responsable de la gestion du fichier

Le 25/10/2011 02:17, Mickaël Wolff a écrit :

$f = new my_file_classic;
$f->open();
// S'il y a eu une erreur, on ne peut pas la traiter facilement sans
// utiliser de variable globale, ou en faisant gérer l'erreur par la
// classe responsable de la gestion du fichier

Ok, cet exemple est parlant. Merci pour tes efforts d'éclaircissement.