[PHP 5.3] Question à propos de l'opérateur "OR" (comme dans "or die") [Résolu]

[bastountan]

Salut !

Cela fait maintenant quelques années que je travaille avec PHP et j'ai bien sûr l'habiture d'utiliser la méthode suivante:

Code :

$link = mysql_connect(...) or die('Impossible de se connecter au serveur MySQL');

Aujourd'hui j'ai fais quelques tests sur la lecture de fichier avec un ami, et je me suis posé une question en utilisant la fonction file() (récupère le contenu d'un fichier sous forme de tableau).
Celle-ci lance une erreur lorsque le fichier lu n'existe pas sur le serveur.

J'avais donc commencé à faire ceci:

Code :

$log_file = @file('fichier_de_log.log') or die(...);

Puis j'ai eu l'idée d'écrire ceci:

Code :

1
2
3
4
5
$log_file = @file('fichier_de_log.log') or $log_file = array();
 
if (count($log_file) > 0) {
     [TRAITEMENT]
}

Derrière cela j'ai une boucle foreach() qui me permet de traverser le contenu du fichier.
L'idée est donc que, lorsque je vérifie la taille du tableau (count), j'affiche une erreur si le tableau est vide.
La ligne du "or" me permet donc de définir un tableau vide si le fichier est inexistant, ce qui affichera donc l'erreur par la suite.

J'ai testé le code, et ce dernier fonctionne sans afficher d'erreur, mais je me demande quand même cela est normal ?
Peut-on vraiment faire cela et est-ce "propre" ?

Car, si c'est vraiment une technique qui marche, je pourrais être amené à m'en servir assez régulièrement en fin de compte !

Merci d'avance pour vos réponses !

[stealth35]

pas besoin de or die c'est une mauvaise pratique dans ce cas la (pour mysql aussi), il suffis de faire un file_exists et/ou is_readable en premier, je te déconseille aussi de mettre des @
si derriere c'est pour lire des CSV utilise fgetcsv en SplFileObject ou en fopen

[ABCIWEB]

Envoyé par stealth35

... il suffis de faire un file_exists et/ou is_readable en premier, je te déconseille aussi de mettre des @

Oui c'est vrai que l'on conseille d'éviter d'utiliser l'opérateur de suppression des erreurs "@" et de gérer les erreurs soit-même, mais dans ce cas je me demande si au final (niveau utilisation des ressources globales) le file_exists() suivi d'un file() n'est pas plus gourmand

[stealth35]

Envoyé par ABCIWEB

Oui c'est vrai que l'on conseille d'éviter d'utiliser l'opérateur de suppression des erreurs "@" et de gérer les erreurs soit-même, mais dans ce cas je me demande si au final (niveau utilisation des ressources globales) le file_exists() suivi d'un file() n'est pas plus gourmand

http://www.php.net/manual/en/languag...trol.php#99805

et même si c'etait l'inverse je pense pas que la question est à se posé, on fait d'abord un code propre et ensuite on voit les perfs, surtout qu'ici celui qui va prendre toute la ressources c'est bien file et si il fait un boucle pour traité derrière il a plus intérêt a faire du stream

[RunCodePhp]

Salut

Juste pour rejoindre ce qui a été déjà dit, soit que les @ ou autre techniques qui masquent les erreurs n'est pas une bonne approche.
C'est un peu comme débrancher les organes de sécurité ou d'alerte sur des machines/équipements.

Ce que tu évoque, c'est la gestion des erreurs, et ceci peu se gérer simplement, ne serait ce quand on débute et qu'on ne sait pas trop, c'est d'agir sur 2 directives du php.ini :
display_error et error_reporting
Le error_reporting le définir à E_ALL qui correspond à un niveau d'erreur.
Pour le display_error, il y a une alternative normalement :
Quand on développe chez soit, on l'a définie à On, comme ça tous les messages seront affichés, ça aidera alors à corriger son code
Pour le site sur son hébergeur (en production), on la définie à Off, aucun message affichés, mais ils seront dans un fichiers log dispo.

Certes, cette manière ci-dessus reste basique, mais ça reste néanmoins un bon début à mon sens.

[burndev]

bonjour,

Envoyé par stealth35

pas besoin de or die c'est une mauvaise pratique dans ce cas la (pour mysql aussi), il suffis de faire un file_exists et/ou is_readable en premier, je te déconseille aussi de mettre des @
si derriere c'est pour lire des CSV utilise fgetcsv en SplFileObject ou en fopen

En plus il serait beaucoup plus simple de levé une exception et de la traitée avec un try catch.

enfin il serait bon que l'on finissent par déprécié ce genre de commandes nœud nœud qui viennent d'un autre temps

bon courage

[stealth35]

Envoyé par burndev

bonjour,



En plus il serait beaucoup plus simple de levé une exception et de la traitée avec un try catch.

enfin il serait bon que l'on finissent par déprécié ce genre de commandes nœud nœud qui viennent d'un autre temps

bon courage

on va pas mettre des exceptions partout, la seul vrai solution c'est de tester si le fichier existe ou pas, tu vas en faire quoi ton exception après ? un exit avec le message d'erreur ? si c'est ça c'est ridicule, si c'est pour autre chose de toute façon les log sont la pour ça donc c'est ridicule aussi.

[burndev]

Envoyé par stealth35

on va pas mettre des exceptions partout, la seul vrai solution c'est de tester si le fichier existe ou pas, tu vas en faire quoi ton exception après ? un exit avec le message d'erreur ? si c'est ça c'est ridicule, si c'est pour autre chose de toute façon les log sont la pour ça donc c'est ridicule aussi.

si on suit ton raisonnement ca marche ou ca marche pas. C'est une façon de voir les choses qui n'est pas du tout mauvaise.

Le contexte que je soulève est uniquement pour mettre évidence une autre façon de faire et de façon global.

[stealth35]

Envoyé par burndev

si on suit ton raisonnement ca marche ou ca marche pas. C'est une façon de voir les choses qui n'est pas du tout mauvaise.

Le contexte que je soulève est uniquement pour mettre évidence une autre façon de faire et de façon global.

je vois toujours pas l’intérêt et l'avantage de cette façon dans ce contexte...

[RunCodePhp]

Envoyé par burndev

En plus il serait beaucoup plus simple de levé une exception et de la traitée avec un try catch.

Plus simple ?

Le code de Bastountan est totalement procédural alors que les Exceptions c'est Objet.
Pour ma part, c'est tout sauf simple de mettre en place une gestion des erreurs et d'exceptions, ça réclame de maitriser la POO justement.
C'est comme vouloir faire le grand écart du jour au lendemain sans même l'avoir fait 1 fois.

[burndev]

Envoyé par RunCodePhp

Plus simple ?

Le code de Bastountan est totalement procédural alors que les Exceptions c'est Objet.
Pour ma part, c'est tout sauf simple de mettre en place une gestion des erreurs et d'exceptions, ça réclame de maitriser la POO justement.
C'est comme vouloir faire le grand écart du jour au lendemain sans même l'avoir fait 1 fois.

effectivement vu sous cette angle je vais trop loin (cela fait bien longtemps que je ne connais plus un code procédurale). Malgré cela, Je ne vois pas en quoi il faut une maitrise du dev objet pour levée une exception.

Même avec du procédurale rien ne t’empêche dans une fonction pour ce genre de manipulation de levée une exception de la non existence ou la non lecture du fichier. Et de traiter ton erreur dans ton traitement plus général.

J'ai exposé une idée qui me parait répondre a un besoin, qui permet de ce décharger d'une multitudes de manipulations diverses (consultation de log, refouille du code, et avec le temps une assiette de spaghettis sans la tomate, ...).

bonne journée a tous

[RunCodePhp]

Envoyé par burndev

Même avec du procédurale rien ne t’empêche dans une méthode pour ce genre de manipulation de levée une exception ...

A bon ?

Quand on lève une Exception, il faut faire appel à un Objet non ?
De même que dans un block try/catch, on tente justement d'attraper l'erreur d'exception déclenchée auparavant, et là encore c'est un Objet qu'on obtient.

On est donc toujours dans un contexte Objet, et si la personne ne maitrise pas la POO, ça va pas être simple.


On peut toujours utiliser une fonction comme trigger_error() pour lancer ses propres erreurs, mais ce n'est en rien des Exceptions, c'est des erreurs tout court.


Tout ce ci n'est pas juste pour contredire, mais il me semble qu'il est bon de proposer des solutions qui seraient en phases.
Là, passer du or die au try/catch, c'est un grand écart, c'est tout sauf simple à mon sens.

[stealth35]

Envoyé par burndev

J'ai exposé une idée qui me parait répondre a un besoin, qui permet de ce décharger d'une multitudes de manipulations diverses (consultation de log, refouille du code, et avec le temps une assiette de spaghettis sans la tomate, ...).

en quoi un try...catch annule la consultation des log et la refouille du code ? je voudrais bien un exemple de cette "simplification"

[radicaldreamer]

Sujet résolu?

file_exists().

[stealth35]

Envoyé par radicaldreamer

Sujet résolu?

file_exists().

dans le fond c'est plus judicieux de faire un is_readable, puisque que le fichier peut exister mais çà lecture peut etre non autorisé

[radicaldreamer]

Envoyé par stealth35

dans le fond c'est plus judicieux de faire un is_readable, puisque que le fichier peut exister mais çà lecture peut etre non autorisé

Je plussoie.