error_reporting - Divida los errores de PHP y los errores de aplicación

ini_set(''error_reporting'', e_all);

Question

Estoy trabajando en una aplicación y se produjo una pregunta. Estaba pensando en dejar los errores de PHP por un lado (estarían ingresando en la base de datos o en un archivo) y gestionar otros errores (como "Su nombre de usuario no es válido" o "Su contraseña incorrecta" o "La imagen no pudo" ser cargado ") con el famoso método try-catch. ¿Es bueno manejar completamente este tipo de errores solo con try-catch?

Answer 1

Los errores y las excepciones son una cuestión técnica, mientras que la validación es asunto de negocios. Si maneja Negocios, TRY / CATCH maneja cosas técnicas que no mezclan y no debe mezclarlos. Hay momentos en los que debe usar un if que arroja una excepción (material PHP) pero esa es la necesidad en el nivel de framework / arquitectura, por ejemplo

if(database_error_handle_raises_error()) {
throw new MyDatabaseException(driver_raised_error);
}

De esta forma, puedes controlar mejor los errores. Pero la regla se mantiene: Try / Catch / Throw = técnico If / Else Switch = business

Answer 2

Para los errores del usuario final, debe introducir un sistema de manejo de nivel de aplicación por separado.

Las excepciones son útiles para manejar condiciones de error (errores que surgen en la producción), mientras que los errores personalizados E_USER_ son los más adecuados para señalar problemas de datos / depuración / seguridad (todo lo que se debe manejar en la etapa de desarrollo).

Answer 3

Pienso: no lo es, porque esto no son errores o excepciones, sino simplemente entradas inválidas. También son bastante comunes y en este contexto no son una excepción en el sentido de la palabra.

Por otro lado, dado que cada excepción interrumpe la ejecución actual, puede llevar a un comportamiento inesperado, cuando no se ejecuta algún código, simplemente porque alguien ingresó un nombre de usuario desconocido o algo así. En caso de errores o excepciones, generalmente desea detener la ejecución, ya que supone que la ejecución no es (razonable) posible (hasta que capte la excepción y continúe).

Answer 4

Utilizo una clase de registro personalizada que escribí y la configuré como el manejador de errores y excepciones predeterminados, y también proporcioné métodos de "depuración", "información", "advertencia", "éxito" y "en desuso" para el registro manual ( y opcionalmente mostrar) mensajes.

La ventaja es que muestra un volcado de las variables en el alcance actual cuando se produce un error real, en lugar de solo decirle dónde ocurrió.

Answer 5

La principal ventaja de las excepciones es su comportamiento de "petite mort", un bloque local die() dentro de try{} , lo que impide la ejecución de más códigos.

Si bien es bastante útil en el manejo de errores de aplicación, no es tan bueno cuando se trata de validar la entrada del usuario. Si un usuario cometió 3 errores al completar un formulario, sería misericordioso mostrarlos todos a la vez, no uno tras otro.

Más bien necesita el patrón POST / Redirect / GET para manejar los errores del usuario:

<?
if ($_SERVER[''REQUEST_METHOD'']==''POST'') {
$err = array();
//performing all validations and raising corresponding errors
if (empty($_POST[''name'']) $err[] = "Username field is required";
if (empty($_POST[''text'']) $err[] = "Comments field is required";
if (!$err) {
//if no errors - saving data and redirect
header("Location: ".$_SERVER[''PHP_SELF'']);
exit;
} else {
// all field values should be escaped according to HTML standard
foreach ($_POST as $key => $val) {
$form[$key] = htmlspecialchars($val);
}
} else {
$form[''name''] = $form[''comments''] = '''';
}
include ''form.tpl.php'';
?>