Php mkdir( ) la gestion des exceptions

mkdir() fonctionne correctement à cette question est plus sur la capture des erreurs. Au lieu de l'impression de la présente lorsque le répertoire existe, je voudrais juste avoir écrire un message à moi dans un journal personnalisé. Comment puis-je créer cette exception.

Warning: mkdir() [function.mkdir]: le Fichier existe

OriginalL'auteur Arcabard | 2010-04-21

  1. 10

    Je voudrais juste avoir écrire un message à moi dans un journal personnalisé.

    la solution est très facile. PHP ont déjà tout pour vous:

    ini_set('display_errors',0);
ini_set('log_errors',1);
ini_set('error_log','/path/to/custom.log');

    ou les mêmes paramètres dans le php.ini ou .htaccess

    Je pense qu'il serait mieux que d'écrire chaque erreur possible manuellement

    Si vous ne voulez pas de cette erreur afin d'être enregistré (comme c'est peut-être pas d'erreur mais une partie de la logique de l'application), vous pouvez vérifier le dossier de l'existence de la première

    if (!file_exists($folder)) mkdir($folder);
else {/*take some appropriate action*/}
    Vous avez saisi ce que je voulais faire. Je ne peux éviter la situation entièrement à l'aide file_exsists(). J'ai utilisé votre réponse à résoudre mon problème. Je Vous Remercie.
    Je dois dire que les deux réponses où le bien et le nikc réponses est certainement plus techniquement correcte, en particulier sur la gestion de l'erreur. J'imagine que des Éclats d'obus savais que je viens de vissage et n'aurait pas besoin de gérer les erreurs si j'ai juste fait les choses =)

    OriginalL'auteur Your Common Sense

  2. 3

    Vous pouvez réécrire le système d'appel de la fonction avec une classe comme ceci:

    file: system.php 

    namespace abc;

class System {

    const CAN_NOT_MAKE_DIRECTORY = 1;

    static public function makeDirectory($path) {
        $cmd = "mkdir " . $path;
        $output = \shell_exec($cmd . " 2>&1"); //system call
        if ($output != "") {
            throw new \Exception($output, System::CAN_NOT_MAKE_DIRECTORY);
        }
        return(\TRUE);
    }

}

    Ensuite, vous pouvez appeler la méthode et intercepter l'exception:

    file: index.php 

    namespace abc;
require 'system.php';

try {
    System::makeDirectory($directoryName);
} catch (\Exception $e) {
    throw new \Exception($e->getMessage(), System::CAN_NOT_MAKE_DIRECTORY);
}

    Maintenant, vous pouvez traiter toutes les erreurs de système avec la try {...} catch(...) {...} finally {...} normalement.

    OriginalL'auteur Ruben Kazumov

  3. 2

    Vous pouvez arrêter le message d'erreur de l'affichage, soit par la suppression de messages d'erreur à l'échelle mondiale (dans la configuration ou de l'exécution) avec le display_errors paramètre, ou au cas par cas par la préfixation de l'appel de la fonction avec un @caractères. (E. g. @mkdir('...')).

    Vous pouvez ensuite vérifier avec error_get_last quand mkdir retourne false.

    Pour l'enregistrement d'erreur global règles s'appliquent. Vous pouvez vous connecter erreurs manuellement avec error_log.

    Pour en savoir plus, consultez la section du manuel sur Erreur de manipulation.

    Edit:

    Comme suggéré dans les commentaires, un gestionnaire d'erreur personnalisé est également possible, sans doute plus robuste (en fonction de la mise en œuvre), mais certainement plus élégant, solution.

    function err_handler($errno, $errstr) {
    //Ignore or log error here
}

set_error_handler('err_handler');

    De cette façon, le message d'erreur s'affiche pas, sauf si vous explicitement écho. Notez, cependant, lors de l'utilisation d'un gestionnaire d'erreur personnalisé error_get_last sera de retour NULL.

    Je tiens à souligner qu'il est de bonne pratique ainsi que de constructif pour le commentaire lorsque downvoting. (Ne pas oublier la politesse.)
    Je n'ai pas downvote vous, mais peut-être que c'est parce que quelqu'un a vu l'opérateur @et la considère comme une mauvaise pratique? (Je n'ai, moi-même, je vous suggère un gestionnaire d'erreur personnalisé au lieu de cela, avec set_error_handler, mais je pense que cette réponse est encore très valide et utile.)
    En effet, un gestionnaire d'erreur personnalisé serait une solution plus élégante. Mais dans les cas comme décrit, je pense que l'opérateur @est une solution acceptable, car il est pour moi comme une situation.

    OriginalL'auteur nikc.org