Zend FR

sekaijin · 21-04-2009 18:10:48

bonjour à tous

ZF utilise encore beaucoup de @function pour ne pas afficher d'erreur lors de certains appels.

je me demandais s'il ne serait pas opportun de proposer à ZF une nouvelle approche qui ne demanderais que peu de refactoring

par exemple une classe statique qui reproduirait les même appel mais sans avoir à utiliser @
il suffirait alors de faire un rechercher remplacer sur tout ZF pour obtenir une version propre
@fopen(...);
Zend_File::open(...);
voici donc une ébauche d'une telle classe.

Code:

class Zend_File
{
    private static $_throwException = false;
    
    public static function setThrowException($throw = true)
    {
        self::_throwException = $throw;
    }
    
    public static function isReadable($filename)
    {
        set_error_handler(create_function('$errno, $errstr, $errfile, $errline',
            'throw new ErrorException($errstr, 0, $errno, $errfile, $errline);'));
        try {
            if (!$fh = fopen($filename, 'r', true)) {
                return false;
            }
            fclose($fh);
            restore_error_handler();
            return true;
        } catch (Exception $e) {
            if (self::_throwException) throw $e;
            restore_error_handler();
            return false;
        }
    }
    
    public static function open($filename, $mode, $use_include_path = false, $context = null)
    {
        set_error_handler(create_function('$errno, $errstr, $errfile, $errline',
            'throw new ErrorException($errstr, 0, $errno, $errfile, $errline);'));
        try {
            if (null == $context) {
                $fh = fopen($filename, $mode, $use_include_path)
            } else {
                $fh = fopen($filename, $mode, $use_include_path, $context)
            }
            restore_error_handler();
            return true;
        } catch (Exception $e) {
            if (self::_throwException) throw $e;
            restore_error_handler();
            return false;
        }
    }
    
    public static function close($handle)
    {
        set_error_handler(create_function('$errno, $errstr, $errfile, $errline',
            'throw new ErrorException($errstr, 0, $errno, $errfile, $errline);'));
        try {
            fclose($handle);
            restore_error_handler();
            return true;
        } catch (Exception $e) {
            if (self::_throwException) throw $e;
            restore_error_handler();
            return false;
        }
    }
    
    public static function read($handle, $length)
    {
        set_error_handler(create_function('$errno, $errstr, $errfile, $errline',
            'throw new ErrorException($errstr, 0, $errno, $errfile, $errline);'));
        try {
            $d = fread($handle, $length);
            restore_error_handler();
            return $d;
        } catch (Exception $e) {
            if (self::_throwException) throw $e;
            restore_error_handler();
            return false;
        }
    }
    
    public static function getString($handle, $length = null)
    {
        set_error_handler(create_function('$errno, $errstr, $errfile, $errline',
            'throw new ErrorException($errstr, 0, $errno, $errfile, $errline);'));
        try {
            if (null == $length) {
                $d = fgets($handle);
            } else {
                $d = fgets($handle, $length);
            }
            restore_error_handler();
            return $d;
        } catch (Exception $e) {
            if (self::_throwException) throw $e;
            restore_error_handler();
            return false;
        }
    }
}

mon propos ici n'est pas de discuter de l'implémentation (qui n'est qu'un exemple de ce qu'on peu faire)
mais de l'opportunité de le faire.

en utilisant cette approche et en supprimant tous les @function de ZF in devient possible d'obtenir une gestion homogène des erreurs en installant au démarrage de ZF un handler_error qui transforme les erreurs en exception
du coup il n'y a plus que des exception et pas d'erreur

aujourd'hui si on fait ça

Code:

function exception_error_handler($errno, $errstr, $errfile, $errline ) {
    throw new ErrorException($errstr, 0, $errno, $errfile, $errline);
}
set_error_handler("exception_error_handler");

ZF ne fonctionne plus car il teste les fichier et les dossier avec des @

je ne sais pas si ça vous parle mais je pense que c'est une bonne solution pour éradiquer les @

A+JYT

Julien · 21-04-2009 19:24:08

un

Code:

try {
$f = new SplFileObject($filename, $mode, $useIncludePath);
} catch (RuntimeException $e) { }

permet de vérifier l'existence d'un fichier sans utiliser de @ mais la gestion native des exceptions de la SPL.
Aussi, SplFileObject possède bcp de méthodes dont évidemment pour lire, écrire et fermer le fichier.

Je pense qu'une telle solution peut être envisageable pour ZF2 ^^

sekaijin · 21-04-2009 20:56:49

merci pour l'info
je vais regarder ça

mais plus que le choix technologique c'est sur le fond que je pose la question.

j'ai le sentiment que ZF aurait à y gagner de supprimer les appels avec des @
et je voudrais savoir si ce sentiment est partagé

je vais faire un inventaire de l'utilisation des @ pour voir l'ampleur de la tâche.

A+JYT

MoineauDeParis · 22-04-2009 13:20:40

sekaijin a écrit:
j'ai le sentiment que ZF aurait à y gagner de supprimer les appels avec des @
et je voudrais savoir si ce sentiment est partagé

Si, comme je l'ai toujours entendu dire, y compris lors de formations Zend, l'usage du @ ralentit forcément l'exécution en provoquant (simulant) deux ini_set() successifs et donc relecture de la config, alors oui ça paraît une excellente idée de s'en affranchir.
D'autre part, l'usage du @ masque une erreur potentielle qu'il serait souvent plus judicieux de lever dans une exception pour écrire plus proprement.
Donc oui, je partage ;-)

Delprog · 24-04-2009 15:13:23

Bonjour,

+1 pour tout ça.

Je n'ai jamais été partisan de l'utilisation des @ dans les appels de fonctions.
Je suis aussi dans l'idée que chaque erreur doit être ciblée et traitée, et non cachée.

Si on ajoute à ça le ralentissement lors de l'exécution comme le dit MoineauDeParis, pour moi cet opérateur est inutile et à ne pas utiliser. J'aurais tendance à le classer dans la catégorie "feinte".

A+ benjamin.

ndesaleux · 24-04-2009 16:11:21

tout pareil, j'aime pas le @ sauf dans les emails et potentiellement les preg_* ^^

Dernière modification par ndesaleux (24-04-2009 16:11:36)

mikaweb · 24-04-2009 20:19:18

On m'a toujours appris de ne pas l'utiliser pour les raisons citées plus haut.
Puis en règle générale, il ne faut pas cacher la merde aux chats.

Mieux vaut afficher les erreurs qui puissent ensuite être réparée que les cacher et les ignorer.

elkolonel · 27-04-2009 09:45:45

Hello Seikajin,

As tu pu regarder le taux de @function dans le code du ZF ?
Est ce utiliser massivement ou modérement ?

++

sekaijin · 27-04-2009 10:47:24

je n'ai pas tout investi mais il y a du boulot

sekaijin · 27-04-2009 21:17:27

bonsoir

après une évaluation sur la version 1.7.5 minimal
j'ai dénombre 232 usage de @
il y a dans cette version 91 fichier impacté

pour une grande partie il s'agit de @fopen de @fclose. il faut tenir compte de l'usage de ce couple d'appel pour tester la lisibilité d'un fichier qui peut être obtenu par la SPL en une opération.
déjà dans ce cas là le nombre brut de @fonction n'est pas pertinent mais juste un indicateur

il y a aussi des @fread @filesize @Zend_Loader::loadClass !! @fsockopen @$dom->loadXML @file_put_contents
@$this->_doc->loadHTML @fseek @filemtime @fgets @fputs @fwrite @file_put_contents @finfo_open @!$accConf['output_cache_enabled'] @flock

je vais continue mes investigation car des chose comme
@!$accConf['output_cache_enabled'] sont pour le moins barbare.
je vais me pencher sur la version 1.8 complète cette fois.

200 corrections me semble quelque chose d'abordable. par contre je pense qu'il faut avant de commencer se coordonner avec l'équipe de Dev car c'est un impact non négligeable.

Savez vous s'il y a une référence quelque part sur les composants de ZF qui dépendent de la SPL

A+JYT

Zend FR

#1 21-04-2009 18:10:48

pour l'erradication des @fopen dans ZF

Code:

Code:

#2 21-04-2009 19:24:08

Re: pour l'erradication des @fopen dans ZF

Code:

#3 21-04-2009 20:56:49

Re: pour l'erradication des @fopen dans ZF

#4 22-04-2009 13:20:40

Re: pour l'erradication des @fopen dans ZF

sekaijin a écrit:

#5 24-04-2009 15:13:23

Re: pour l'erradication des @fopen dans ZF

#6 24-04-2009 16:11:21

Re: pour l'erradication des @fopen dans ZF

#7 24-04-2009 20:19:18

Re: pour l'erradication des @fopen dans ZF

#8 27-04-2009 09:45:45

Re: pour l'erradication des @fopen dans ZF

#9 27-04-2009 10:47:24

Re: pour l'erradication des @fopen dans ZF

#10 27-04-2009 21:17:27

Re: pour l'erradication des @fopen dans ZF

Pied de page des forums