try - php error log

La gran teoría unificada del manejo de errores de PHP.

Question

también conocido como Buscador de errores genérico (ΟΚ para usar comercialmente)

Dudo que sea el mejor programador de PHP, así que, aunque tengo mi propio controlador de error genérico para set_error_handler() , me pregunto qué hacen los demás y si hay un "mejor" (lo siento si eso suena subjetivo, solo quiero extraer enfoques generales (pero incluso la etiqueta de "mejores prácticas" se ha eliminado de SO)).

Para ser objetivo al respecto, esto es lo que creo que se necesita. Corríjame si me equivoco y señáleme un buen código si está de acuerdo.

• Quiero capturar la mayor cantidad de información posible, sin saber cuál fue el error.

• así, por ejemplo, tiene sentido volcar la pila de llamadas.

• y $_GET , $_POST y $_SESSION .

• y quiero que la pila de llamadas y los Globales estén bastante impresos

• Quiero un diseño de ''texto simple'', no CSS y JS de fantasía para expandir / contraer la información. Es posible que mis usuarios tengan que cortar / pegar en el correo electrónico o incluso imprimir y enviar por fax.

• Me gustaría poder agregar un encabezado de mi propio diseño, preferiblemente como un parámetro, pero puedo hackear el código si es necesario. El encabezado puede incluir la versión del programa, la marca de tiempo, etc. (y, en mi caso, tengo una pista de auditoría, por lo que puedo incluir las últimas acciones del usuario, lo que provocó el bloqueo).

• algunos usuarios pueden permitir que mi código envíe automáticamente el informe por correo electrónico, otros pueden desear obtener una vista previa del mismo y enviarlos por correo electrónico, mientras que otros no desean que yo envíe un correo electrónico.

Answer 1

Exponer todo su manejo de errores al usuario final no es una buena idea.

1) expone la estructura interna de su código, está bien, entonces debería ser seguro incluso cuando un atacante potencial tiene el código fuente completo, pero no tiene sentido hacer su vida más fácil.

2) ¿Realmente crees que el usuario final copiará concienzudamente toda la información y se la enviará?

3) estás abrumando al usuario con mucha información que no le importa.

La forma en que manejo esto es capturar tanta información como la parte práctica del servidor (y escribirla en un archivo plano cuando se produce un error) y luego proporcionar un mensaje de error significativo al usuario, que incluye una referencia simple de dónde puedo encontrar el error en los registros. Para sistemas a gran escala también recomendaría capturar una huella digital del error (por ejemplo, los últimos 6 dígitos del hash md5 del seguimiento de la pila) para permitir que un servicio de asistencia administre y clasifique múltiples incidentes reportados del mismo fallo subyacente.

Recuerde que con PHP todos los datos se borran cuando se completa el script. Si estaba escribiendo una aplicación Java o un programa en C, entonces realmente no desea acumular datos constantemente, por lo que las únicas opciones son escribir entradas de información / depuración en un registro, luego, una vez que se produce un error, escriba un seguimiento de pila al registro. Pero con PHP para páginas web, generalmente mantengo un registro de estos en una variable de PHP, luego lo escribo en un archivo cuando ocurre un error junto con un seguimiento de la pila (o cuando el script se completa y puse una marca en el código, por ejemplo, a través de la sesión, para analizar cómo se comporta en escenarios sin error).

La cantidad de detalles que registre depende de usted; por lo general, registro todos los puntos de entrada y salida de fn y todas las consultas de SQL.

p.ej

function logit($msg)
{
global $runlog;
static $basetime;
if (!$basetime) $basetime=time();
$runlog.="+" . time()-$basetime . "s : " . $msg . "/n";
}

Answer 2

No puedo creer que esto no haya sido sugerido todavía.

En mi empresa solo usamos Exceptions con un controlador de errores personalizado. El controlador de errores compilará un mensaje de depuración con:

• OBTENER, POST, COOKIES, SESIÓN, GLOBALES
• Un rastro
• Un mensaje de error (ya sea el mensaje en la Excepción o la advertencia , sí, también debería detectar las advertencias, incluso los errores de ESTRICCIÓN ).

Luego, el mensaje se envía a un servidor de monitoreo , si eso falla, intentará enviarnos un correo electrónico , si falla, intentará iniciar sesión en una base de datos (y si falla, iniciará sesión en un archivo ). Si el error es un error "fatal" en el sentido de que su salida no puede ser garantizada, puede elegir lanzar un encabezado de 500 e imprimir un mensaje predeterminado "oops".

Le aconsejo que siempre informe automáticamente todos los errores. Los únicos errores que no desea conocer son los errores causados ​​por una entrada errónea del usuario. En ese caso, los errores deben presentarse al usuario de alguna manera. Descubrí que para cada excepción puede identificar si se trata de un error en su sistema o de un error de un usuario. Por ejemplo: enlazando a una página, y luego eliminando la página (esto causará un 404). Usted no quiere saber sobre el 404, pero su cliente lo hace.

La razón por la que siempre quieres saber acerca de todos los errores es simple. Si su sistema tiene un error, no lo sabrá a menos que se encuentre con usted mismo o que su cliente lo informe (lo que casi nunca hace). Solíamos tener un sistema que era bueno para ocultar todos los errores y estaba súper con errores. Comenzamos a exponer todos los errores y dos años más tarde es una aplicación muy estable.

Adicionalmente. Hay un truco que puedes usar para atrapar los Fatal Errors molestos. Puede usar register_shutdown_handler para registrar una función que siempre se ejecutará después de que su script PHP haya finalizado. Entonces puede usar error_get_last para verificar si hay un error fatal. A continuación, puede repetir los pasos anteriores para que se conozca el error. Esto funciona, lo uso todo el tiempo.

Para redondearlo. Lo que elija para el informe de errores no tiene nada que ver con lo que verá el usuario de su aplicación. Puede elegir darle un informe de error e incluso pedirle su opinión en ese momento. Pero la mayoría de las veces solo hay un error en su sistema, por lo que el usuario realmente no puede hacer mucho con él.

Answer 3

Sugiero ir por el camino de "Excepciones".

Deseche las excepciones cuando haya un error de usuario, y puede convertir los errores de php en excepciones, como esto:

function exception_error_handler($errno, $errstr, $errfile, $errline ) {
throw new ErrorException($errstr, 0, $errno, $errfile, $errline);
}
set_error_handler("exception_error_handler");

Aunque este tipo de comportamiento funciona mejor en un tipo de entorno de POO. Si no tiene un solo punto de entrada (como un controlador frontal), también puede detectar excepciones con esto:

function myException($exception)
{
echo "<b>Exception:</b> " , $exception->getMessage();
}
set_exception_handler(''myException'');

La depuración simple con excepciones sería algo como esto:

function parseException($e) {
$result = ''Exception: "'';
$result .= $e->getMessage();
$trace = $e->getTrace();
foreach (range(0, 10) as $i) {
$result .= ''" @ '';
if (!isset($trace[$i])) {
break;
}
if (isset($trace[$i][''class''])) {
$result .= $trace[$i][''class''];
$result .= ''->'';
}
$result .= $trace[$i][''function''];
$result .= ''(); '';
$result .= $e->getFile() . '':'' . $e->getLine() . "/n/n";
}
return $result;
}

A partir de ahí la evaluación de los globales es un paseo por el parque. Puedes buscar inspiración en la barra de herramientas de depuración de Symfony Framework, que ofrece muchas de estas solicitudes.