116 votes

PHP de gestion d'Erreur: die() Vs trigger_error() Vs jeter l'Exception

En ce qui concerne la gestion des Erreurs en PHP -- Que je sais qu'il y a 3styles

  1. die()ou exit() style:

    $con = mysql_connect("localhost","root","password");
    
    if (!$con) {
     die('Could not connect: ' . mysql_error());
    }
    
  2. throw Exception style:

     if (!function_exists('curl_init')) {
    
          throw new Exception('need the CURL PHP extension. 
                               Recomplie PHP with curl');
        }
    
  3. trigger_error() style:

    if(!is_array($config) && isset($config)) {
            trigger_error('Error: config is not an array or is not set', E_USER_ERROR);
        }
    

Maintenant, Dans le manuel php tous les trois sont utilisés.

  • Ce que je veux savoir, c'est qui le style que je préfère et pourquoi?

  • Ces 3 sont à déposer dans les remplacements de chacun des autres et peuvent donc être utilisés de façon interchangeable?

Un peu OT: Est-ce juste moi ou tout le monde pense que PHP options de gestion des erreurs sont tout simplement trop nombreux à mesure qu'il confond les développeurs php.

85voto

Linus Kleen Points 15925

Le premier ne doit jamais être utilisé dans le code de production, puisque c'est le transport des informations non pertinentes pour les utilisateurs finaux (un utilisateur ne peut pas faire quelque chose "Ne peut pas se connecter à la base de données").

Vous lancer des Exceptions si vous savez que, à une certaine critique du point de code, votre application peut échouer et vous souhaitez que votre code pour récupérer à travers de multiples appelez-niveaux.

trigger_error() permet de fine-grain de rapport d'erreur (par l'utilisation de différents niveaux de messages d'erreur) et que vous pouvez masquer ces erreurs et les utilisateurs finaux (à l'aide d' set_error_handler()), mais ont encore leur être affiché sur l'écran pendant le test.

Aussi trigger_error() peut produire non mortels, les messages important au cours du développement qui peut être supprimée dans le code de production à l'aide d'un gestionnaire d'erreur personnalisé. Vous pouvez produire des erreurs fatales, trop (E_USER_ERROR) mais ceux-ci ne sont pas récupérables. Si vous déclenchez l'un de ceux-ci, l'exécution du programme s'arrête à ce point. C'est pourquoi, pour les erreurs fatales, des Exceptions doivent être utilisés. De cette façon, vous aurez plus de contrôle sur votre programme de flux:

// Example (pseudo-code for db queries):

$db->query('START TRANSACTION');

try {
    while ($row = gather_data()) {
       $db->query('INSERT INTO `table` (`foo`,`bar`) VALUES(?,?)', ...);
    }
    $db->query('COMMIT');
} catch(Exception $e) {
    $db->query('ROLLBACK');
}

Ici, si gather_data() tout simplement crevé (à l'aide d' E_USER_ERROR ou die()) il y a une chance, précédente INSERT déclarations ont été faites dans votre base de données, même si ce n'est pas souhaitée et vous n'avez aucun contrôle sur ce qui se passera ensuite.

10voto

Emil Vikström Points 42251

J'ai l'habitude d'utiliser la première méthode simple pour le débogage de code de développement. Il n'est pas recommandé pour la production. Le mieux est de lever une exception, que vous pouvez attraper dans d'autres parties du programme et de faire une gestion d'erreur.

Les trois styles ne sont pas des substituts pour les uns les autres. Le premier n'est pas une erreur, mais juste un moyen d'arrêter le script de sortie et quelques infos de débogage pour vous d'analyser manuellement. Le second n'est pas une erreur en soi, mais sera converti en un message d'erreur si vous n'avez pas l'attraper. Le dernier est le déclenchement d'une véritable erreur dans le moteur PHP, qui seront traitées en fonction de la configuration de votre environnement PHP (dans certains cas indiqués à l'utilisateur, dans d'autres cas, tout simplement connecté à un fichier ou pas sauvé).

Prograide.com

Prograide est une communauté de développeurs qui cherche à élargir la connaissance de la programmation au-delà de l'anglais.
Pour cela nous avons les plus grands doutes résolus en français et vous pouvez aussi poser vos propres questions ou résoudre celles des autres.

Powered by:

X