2011-03-24 15 views
5

Acabo de leer Why to never use 'or die'.Cómo morir con elegancia?

Estoy más confundido que nunca. Estoy validando una forma complicada y voy a muchos niveles anidados de sentencias if y qué no y paso una variable al formulario que se llama $ status que solo puede ser 'nuevo' o 'editar'. Luego, cuando el usuario envía el formulario para ser validado de nuevo, el formulario pasa junto con el valor $ status como un campo oculto ($ _POST). Quiero asegurarme de que el usuario no pueda cambiar esto accidentalmente, así que quiero detectar el error si pasa algo diferente a "nuevo" o "edición". (Aunque me gustaría eliminar por completo la posibilidad de que el usuario que afectan a esta variable en un mundo ideal.)

por lo que pensé que iba a utilizar DIE() en una sentencia if

<nested ifs> 
    Select ($status){ 
     Case 'edit': 
      break; 
     Case 'new': 
      break; 
     default: 
      //using example from article 
      trigger_error("An error that should not occur has occurred", E_USER_ERROR); 
      break; 
    } 
</nested ifs> 

I don' realmente entiendo cómo esto es más limpio que morir()? Básicamente me gustaría llamar a otra función que muestra al usuario algunas opciones de lo que pueden hacer en este momento para arreglar el error, pero quiero que el código deje de ejecutarse por completo, ya que no quiero una sentencia if más abajo para continuar el análisis cualquier cosa y generando un error cuando encuentra algo que no sea 'nuevo' o 'editar'.

No estoy seguro de lo claro que soy, así que no dude en pedirme que explique los puntos confusos. (o mejor aún, ¿puede ser pirateado un campo de usuario oculto? ¿Cómo prevenir?: P)

+6

+1 Título maravilloso. –

Respuesta

6

trigger_error() desencadena un error que es manejado por un controlador de errores.

Con trigger_error() se puede controlar correctamente errores, por ejemplo:

set_error_handler('ErrorHandler'); 

    function ErrorHandler($errno, $errmsg, $filename, $linenum, $vars) 
    { 
    print '<pre style="line-height: 2em;">'; 
    printf("==> Error in `%s' line %s: %s\n\n", $filename, $linenum, $errmsg); 
    debug_print_backtrace(); 
    print '</pre>'; 

    exit($errno); 
    } 

Este es un ejemplo sencillo, pero nuestra página web muestra una página de error amable y me envía un correo electrónico que soy un idiota y en mal estado en algún lugar :-)

La ventaja sobre die() o exit() debe quedar claro :-)

exit() todavía se puede utilizar cuando se necesita para salir. Por ejemplo, cuando genera una plantilla, la publica y desea que se detenga la ejecución del código. O cuando envía un encabezado header('Location: ...'); y quiere asegurarse de que la ejecución se detenga ... Simplemente no lo use para manejar situaciones inesperadas (es decir, errores).

trigger_error() también le da un mejor grado de control. Puede enviar E_USER_NOTICE cuando desee que la ejecución se detenga pero muestre un aviso, y E_USER_ERROR cuando desee ejecutar detener.

Además, puede escribir funciones de controlador de error más complejas donde algunas IP ven un error, y el resto no ... Kindda es útil para el desarrollo.

Sea cuidadoso con los controladores de errores demasiado complicados, ¿qué ocurre si se produce un error dentro de un manejador de errores ...?Es posible que haya visto Inception :)

+0

¿Dónde encaja el trigger_error() en esto? ¿La función de error de activación llama a set_error_handler que a su vez llama a ErrorHandler? Por cierto estoy mirando este código con admiración: "OH tan brillante": D – Mallow

+1

@ Golpe: Eso es exactamente lo que sucede. Lo bueno de 'set_error_handler' es que puedes establecer varios manejadores para los distintos tipos de errores (manejables). Tenga cuidado, ciertos errores no se pueden manejar, como los errores de análisis. – Charles

+0

¡Esto es maravilloso! Has completado el enlace faltante – Mallow

1

El artículo se ha vinculado a explica por qué no se debe utilizar or die, como en:

$result = mysql_query($query) or die('A MySQL query occurred: ' . mysql_error()); 

Obviamente esto es una mala idea, ya que podría generar la información sensible acerca de su estructura MySQL a un usuario malicioso.

Sin embargo, creo que no hay nada de malo (y creo que el autor del artículo estaría de acuerdo conmigo) en usar die en la forma en que lo está usando, aunque presentar al usuario una lista de opciones ser la mejor forma de manejar esto.

+0

Ah, sospeché que el 'o morir' era su principal objetivo, pero no quería poner mi mano en el fuego. – Mallow

Cuestiones relacionadas