¿Existen patrones para manejar errores en proyectos de PHP?

Question

Me pregunto qué patrones hay para manejar errores en PHP?

Estoy cerca de crear un objeto ErrorManager global que tenga métodos para agregar mensajes. Como toda mi aplicación se compila, cualquier error que se produzca se registra en ese objeto ErrorManager. Al final de mi Front Controller (las últimas líneas del script) le digo al ErrorManager que muestre los errores (si hay alguno). Una cosa elegante en la que pensé: a los visitantes realmente no les importan los detalles técnicos. En su lugar, deberían recibir una bella página de error con un gran "SORRY" y una información de que se informó el error. Luego, el ErrorManager envía un correo electrónico al administrador con toda la información disponible y lo registra en un archivo de registro de errores. Este archivo se puede ver a través del backend, para facilitar el desarrollo.

No tengo idea si esta es una buena estrategia. Apuesto a que conoces mejores :-)

Answer 1

PHP Manual

• http://de3.php.net/errorfunc
• http://www.php.net/manual/en/language.exceptions.php

En general

• http://devzone.zend.com/article/1303-Error-Handling-Stepping-beyond-TrueFalse-Results
• http://devzone.zend.com/article/666-Exceptional-Code---PART-1

En MVC (ej. ZF)

• http://framework.zend.com/manual/en/zend.controller.exceptions.html
• http://www.dragonbe.com/2007/11/error-handling-in-zend-framework.html
• http://www.talkincode.com/a-useful-error-controller-class-for-zend-framework-applications-729.html

Answer 2

Nunca debes dejar que ningún visitante vea ningún mensaje de error técnico. No necesitan verlo y es un defecto de seguridad. Si un usuario descubre una inyección sql, al mostrar el mensaje de error sql, le resulta más fácil resolver la estructura de su base de datos.

En cuanto al correo electrónico, debe tener mucho cuidado con la forma de hacerlo, ya que el administrador puede estar dormido cuando se produce el error y terminar con 20,000 correos electrónicos en su bandeja de entrada cuando se despierte.

Una mejor idea es utilizar un archivo de registro o base de datos y enviar un solo correo electrónico por hora (o día) cuando se produce un error. De esa manera, como máximo, hay 12 correos electrónicos sobre errores.