Manejo de errores de PHP: die () Vs trigger error () Vs throw Exception

En lo que respecta al manejo de errores en PHP there Hasta donde sé hay 3 estilos:

  1. die()o exit() estilo: 

    $con = mysql_connect("localhost","root","password");

if (!$con) {
 die('Could not connect: ' . mysql_error());
}

  2. throw Exception estilo: 

     if (!function_exists('curl_init')) {

      throw new Exception('need the CURL PHP extension. 
                           Recomplie PHP with curl');
    }

  3. trigger_error() estilo: 

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

Ahora, en el manual de PHP se utilizan los tres métodos.

  • Lo que quiero saber es qué estilo debo preferir y por qué?

  • Son estos 3 gota en reemplazos de uno a y por lo tanto se puede utilizar indistintamente?

Ligeramente OT: ¿Soy solo yo o todo el mundo piensa que las opciones de manejo de errores de PHP son simplemente demasiadas en la medida en que confunde a los desarrolladores de php?

Author: Chris Toxz, 2011-08-15
Source

2 answers

El primero nunca debe usarse en código de producción, ya que transporta información irrelevante para los usuarios finales (un usuario no puede hacer nada sobre "No puede conectarse a la base de datos").

Arroja excepciones si sabe que en un determinado punto crítico del código, su aplicación puede fallar y desea que su código se recupere en varios niveles de llamada.

trigger_error() le permite informar de errores de grano fino (mediante el uso de diferentes niveles de mensajes de error) y puede ocultar los errores de los usuarios finales (utilizando set_error_handler()) pero todavía tienen que ser mostrados a usted durante la prueba.

También trigger_error() puede producir mensajes no fatales importantes durante el desarrollo que se pueden suprimir en el código de producción utilizando un manejador de errores personalizado. También puede producir errores fatales (E_USER_ERROR), pero no son recuperables. Si activa uno de ellos, la ejecución del programa se detiene en ese momento. Esta es la razón por la que, para errores fatales, se deben usar excepciones. De esta manera, tendrás más control sobre el flujo de su programa:

// 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');
}

Aquí, si gather_data() simplemente croado (usando E_USER_ERROR o die()) hay una posibilidad, anteriores INSERT declaraciones habrían hecho en su base de datos, incluso si no se desea y no tendría control sobre lo que va a suceder a continuación.

 73
Author: Linus Kleen,
Warning: date(): Invalid date.timezone value 'Europe/Kyiv', we selected the timezone 'UTC' for now. in /var/www/agent_stack/data/www/ajaxhispano.com/template/agent.layouts/content.php on line 61
2011-08-15 09:11:59

Normalmente uso la primera forma de depuración simple en el código de desarrollo. No se recomienda para la producción. La mejor manera es lanzar una excepción, que puede atrapar en otras partes del programa y hacer algo de manejo de errores.

Los tres estilos no son sustitutos directos entre sí. El primero no es un error en absoluto, sino solo una forma de detener el script y generar información de depuración para que pueda analizarlo manualmente. El segundo no es un error per se, pero se convertirá en un error si no lo cogen. El último está desencadenando un error real en el motor PHP que se manejará de acuerdo con la configuración de su entorno PHP (en algunos casos se muestra al usuario, en otros casos solo se registra en un archivo o no se guarda en absoluto).

 7
Author: Emil Vikström,
Warning: date(): Invalid date.timezone value 'Europe/Kyiv', we selected the timezone 'UTC' for now. in /var/www/agent_stack/data/www/ajaxhispano.com/template/agent.layouts/content.php on line 61
2011-08-15 08:44:50