Pregunta En PHP5, ¿debo usar Excepciones o trigger_error / set_error_handler? [cerrado]


¿Cuáles son los pros / contra de hacer de cualquier manera? ¿Hay un camino correcto (tm)?


32
2017-09-13 15:18


origen


Respuestas:


Si desea usar excepciones en lugar de errores para toda su aplicación, puede hacerlo con ErrorException y un controlador de error personalizado (consulte la página ErrorException para un controlador de error de muestra). El único inconveniente de este método es que los errores no fatales arrojarán excepciones, que siempre son fatales a menos que sean detectadas. Básicamente, incluso un E_NOTICE detendrá toda su aplicación si su error al reportar la configuración no los suprime.

En mi opinión, hay varios beneficios al usar ErrorException:

  1. Un controlador de excepciones personalizado le permitirá mostrar mensajes agradables, incluso para errores, usando set_exception_handler.
  2. No interrumpe el código existente de ninguna manera ... trigger_error y otras funciones de error seguirán funcionando normalmente.
  3. Hace realmente difícil ignorar los errores de codificación estúpidos que desencadenan E_NOTICEs y E_WARNINGs.
  4. Puedes usar try/catch para ajustar el código que puede generar un error de PHP (no solo excepciones), que es una buena manera de evitar el uso de @ hack de supresión de errores:

    try {
        $foo = $_GET['foo'];
    } catch (ErrorException $e) {
        $foo = NULL;
    }
    
  5. Puedes envolver todo tu script en un solo try/catch bloquear si desea mostrar un mensaje amigable a sus usuarios cuando ocurre un error no detectado. (Haga esto con cuidado, porque solo se registran errores y excepciones no detectadas).


20
2017-07-15 02:51



Debe usar excepciones en "Circunstancias excepcionales", es decir, cuando llama a un método doFoo () que debe esperar que funcione, si por alguna razón doFoo no puede hacer su trabajo, entonces debe generar una excepción.

Una gran cantidad de viejos códigos php tomaría el enfoque de devolver falsa o nula cuando ocurra una falla, pero esto dificulta la depuración, las excepciones hacen que esta depuración sea mucho más fácil.

Por ejemplo, supongamos que tiene un método llamado getDogFood () que devuelve una matriz de objetos DogFood, si llamó a este método y devuelve un valor nulo cuando algo falla, ¿cómo podrá su código de llamada saber si se devolvió el valor nulo porque hubo un error? o simplemente no hay comida para perros disponible?

En cuanto a las bibliotecas de códigos heredados que utilizan el registro de errores incorporado de php, puede anular el registro de errores con la función set_error_handler (), que podría utilizar para volver a lanzar una excepción genérica.

Ahora que tiene todo su código arrojando excepciones detalladas, puede decidir libremente qué hacer con ellos, en algunas partes de su código puede que desee atraparlos y probar métodos alternativos o puede iniciar sesión utilizando sus propias funciones de registro que podría iniciar sesión en una base de datos, archivo, correo electrónico, lo que prefiera. En resumen: las excepciones son más flexibles.


8
2018-02-08 03:39



Me encanta la idea de usar excepciones, pero a menudo tengo bibliotecas de terceros involucradas, y luego, si no usan excepciones, terminas con 3-4 enfoques diferentes del problema. Zend usa excepciones. CakePHP utiliza un controlador de error personalizado, y la mayoría de las bibliotecas PEAR utilizan el objeto PEAR :: Error.

Yo que HABÍA una sola manera verdadera en este sentido. La ruta personalizada de controladores de errores es probablemente la más flexible en esta situación. Sin embargo, las excepciones son una gran idea si solo está utilizando su propio código o está utilizando bibliotecas que lo usan.

Desafortunadamente en el mundo de PHP todavía estamos sufriendo la negativa a morir de PHP4, por lo que las excepciones, aunque pueden representar las mejores prácticas, han sido increíblemente lentas para ponerse al día mientras todos escriben cosas para poder trabajar tanto en 4 y 5. Esperemos que esta debacle termine ahora, aunque en el momento en que lo haga, tendremos tensiones entre 6 y 5 en su lugar ...

/ yo tengo la cabeza en las manos ...


6
2017-09-13 20:08



Depende de la situación. Tiendo a usar Excepciones cuando escribo lógica de negocios / aplicaciones internas, y trigger_error para Validator y cosas por el estilo.

El profesional de usar Excepciones en el nivel lógico es permitir que su aplicación lo haga en caso de tal error. Permites que la aplicación elija en lugar de que la lógica comercial sepa cómo presentar el error.

Los profesionales de usar trigger_error para Validator y cosas de esa naturaleza son, por ejemplo,

try {
    $user->login();
}  catch (AuthenticationFailureException $e) {
    set_error_handler("my_login_form_handler");
    trigger_error("User could not be logged in. Please check username and password and try again!");
} catch (PersistenceException $pe) { // database unavailable
    set_error_handler("my_login_form_handler"); 
    trigger_error("Internal system error. Please contact the administrator.");
}

donde my_login_form_handler pretiende la cadena y coloca el elemento en un área visible encima del formulario de inicio de sesión.


3
2017-09-13 15:49



Obviamente, no hay "un camino correcto", pero hay una multitud de opiniones sobre este. ;)

Personalmente utilizo trigger_error para cosas que las excepciones no pueden hacer, es decir, avisos y advertencias (es decir, cosas que desea registrar pero no detiene el flujo de la aplicación de la misma manera que los errores / excepciones (incluso si los detecta en algún nivel) )).

También utilizo principalmente excepciones para condiciones que se supone son irrecuperables (para el que llama del método en el que se produce la excepción), es decir, errores graves. No utilizo excepciones como alternativa a devolver un valor con el mismo significado, si eso es posible de una manera no intrincada. Por ejemplo, si creo un método de búsqueda, normalmente devuelvo un valor nulo si no encuentra lo que estaba buscando en lugar de arrojar una EntityNotFoundException (o equivalente).

Entonces mi regla de oro es esta:

  • Siempre que no encontrar algo sea un resultado razonable, me resulta mucho más fácil regresar y verificar valores nulos (o algún otro valor predeterminado) que manejarlo usando una cláusula try-catch.
  • Si, por otro lado, no encontrarlo es un error grave que no está dentro del alcance de la persona que llama para recuperarse, todavía lanzaría una excepción.

La razón para lanzar excepciones en el último caso (en lugar de desencadenar errores) es que las excepciones son mucho más expresivas, dado que se usan subclases de Excepción correctamente nombradas. Encuentro que usar las excepciones de la Biblioteca Estándar de PHP es un buen punto de partida para decidir qué excepciones usar: http://www.php.net/~helly/php/ext/spl/classException.html

Sin embargo, es posible que desee extenderlos para obtener excepciones más semánticamente correctas para su caso particular.


3
2017-09-17 11:34



Introducción

En mi experiencia personal, como regla general, prefiero usar excepciones en mi código en lugar de trigger_error. Esto se debe principalmente a que el uso de Excepciones es más flexible que la activación de errores. Y, en mi humilde opinión, esto también es beneficioso no solo para mí como para el desarrollador de terceros.

  1. Puedo extender la clase Exception (o usar códigos de excepción) para diferenciar explícitamente los estados de mi biblioteca. Esto me ayuda a mí y a desarrolladores de terceros a manejar y depurar el código. Esto también expone dónde y por qué puede fallar sin necesidad de buscar código fuente.
  2. De hecho, puedo detener la ejecución de mi Biblioteca sin detener la ejecución del script.
  3. El desarrollador de terceros puede encadenar mis excepciones (en PHP> 5.3. *). Muy útil para la depuración y puede ser útil para manejar situaciones en las que mi biblioteca puede fallar debido a razones dispares.

Y puedo hacer todo esto sin imponer cómo debe manejar las fallas de mi biblioteca. (es decir, crear funciones complejas de manejo de errores). Puede usar un bloque try catch o simplemente usar un manejador genérico de excepciones

Nota:


3
2017-12-01 02:12



La idea de excepción es elegante y hace que el proceso de manejo de errores sea tan fluido. pero esto solo se aplica cuando tienes clases de excepción apropiadas y en desarrollo de equipo, una cosa más importante son las excepciones "estándar". por lo tanto, si planea usar excepciones, es mejor que primero estandarice sus tipos de excepción, o la mejor opción es usar excepciones de algún marco popular. Otra cosa que se aplica a PHP (donde se puede escribir el orientador de objetos de código combinado con el código estructural), es que si está escribiendo toda su aplicación usando clases. Si está escribiendo orientado a objetos, entonces las excepciones son más seguras. después de todo, creo que el proceso de manejo de errores será mucho más suave con la excepción que trigger_error y esas cosas.


2
2017-09-16 19:39



Las Excepciones son la forma moderna y robusta de señalar una condición de error / una situación excepcional. Usalos, usalos a ellos :)


1
2017-10-04 15:47



Usar excepciones no es una buena idea en la era de la integración de aplicaciones de terceros


-2
2017-11-11 19:22