error handling - try - Manejo de errores PHP: die() Vs trigger_error() Vs throw Exception

try catch php mysql

Question

Con respecto al manejo de errores en PHP: hasta donde sé, hay 3 estilos:

1. die() o exit() :

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

2. throw Exception estilo de throw Exception :

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

3. trigger_error() :

   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 usan los tres métodos.

• Lo que quiero saber es qué estilo debería preferir y por qué?

• ¿Estos 3 se reemplazan entre sí y, por lo tanto, se pueden usar indistintamente?

Ligeramente OT: ¿Somos solo yo o todos piensan que las opciones de manejo de errores de PHP son demasiadas en la medida en que confunden a los desarrolladores de PHP?

Answer 1

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

Lanza Excepciones si sabe que en un determinado punto clave del código, su aplicación puede fallar y desea que su código se recupere en múltiples niveles de llamadas.

trigger_error() permite generar informes de errores de grano fino (mediante el uso de diferentes niveles de mensajes de error) y puede ocultar esos errores de los usuarios finales (usando set_error_handler() ) pero aún así se los debe mostrar durante la prueba.

También trigger_error() puede producir mensajes no fatales importantes durante el desarrollo que pueden ser suprimidos en el código de producción usando un manejador de error personalizado. También puede producir errores fatales ( E_USER_ERROR ) pero esos no son recuperables. Si activa uno de ellos, la ejecución del programa se detiene en ese punto. Por esta razón, para los errores fatales, se deben usar excepciones. De esta forma, tendrás más control sobre el flujo de tu 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 graznó (usando E_USER_ERROR o die() ) hay una posibilidad, las declaraciones INSERT previas habrían llegado a su base de datos, incluso si no se desea y usted no tendría control sobre lo que sucederá a continuación.

Answer 2

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

Los tres estilos no son reemplazos el uno para el otro. 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 lo analice manualmente. El segundo no es un error per se, pero se convertirá en un error si no lo atrapa. El último desencadena un error real en el motor de PHP que será manejado de acuerdo con la configuración de su entorno de PHP (en algunos casos se muestra al usuario, en otros casos solo se registra en un archivo o no se guarda en absoluto).