unreal4u's Personal Network Because my reality… is just your virtuality

Manejar errores en PHP

Conclusiones

Construir un buen sistema de errores es una tarea simple, sin embargo, require un tiempo adicional considerable si queremos considerar todas las posibles consideraciones.
Fuera del juego de palabras previo, es importante verificar todas las entradas, sea por el método que sea: con extensiones como LiveHTTPHeaders para Firefox, es bastante simple alterar el contenido de un formulario con $_POST ya que esta extensión en particular, aparte de mostrar cabeceras, también permite enviarlas.
Especial cuidado también se debe tener con $_GET, puesto que permite una entrada de datos más que directa, lo cual puede ser no muy conveniente en algunos casos. En general, apliquen la siguiente regla: ¿Quieren que la página se pueda guardar directamente como un marcador o favorito? En ese caso, usen $_GET para llegar a ella. Sin embargo, si no se quiere que la página sea guardable como marcador o favorito, ocupen $_POST para llegar a ella.

Pero continuando un poco con el tema original, existe casi una infinidad de errores que pueden producirse y todas ellas tienen distintas maneras de evitarse. Lo único que puedo recomendarles es siempre tratar de verificar absolutamente todo: si se espera un número, verifiquen que efectivamente lo sea antes de ejecutar cualquier acción. (Existen un montón de funciones "is_" para verificar las entradas y por supuesto, también está el poderosísimo filter_var()). Cuando hagan alguna consulta, verifiquen primero que se haya conectado bien a la base de datos y después verifiquen si el número de registros retornados sea mayor a cero y retornen un código de error que pueda ser ejecutado centralizadamente para mayor facilidad y consistencia de la aplicación como un todo.

Por último, una consideración que encuentro muy importante que puede tomarse hasta como una reflexión personal: una vez, mientras me encontraba trabajando en una empresa, a uno de los programadores se le ocurrió borrar la base de datos completa. A los dos segundos de haber hecho eso, empezaron las llamadas de parte de todas las sucursales informando acerca de todo tipo de errores extraños. En el momento mismo no sabíamos qué había pasado, pero bastó con una pequeña reunión de un par de segundos (que fue algo así como "Sorry cabros, pasé a borrar toda la base de datos, mientras la restauro, avísenle a los vendedores") para darnos cuenta de qué había pasado.
Se me ocurrió la idea de decir: "ya, pero en vez de echarnos la culpa, ¿por qué simplemente no decimos que fue una falla del sistema?". Fue ahí donde me dijeron algo a lo cual le encontré toda la razón: nunca se puede decir algo como eso, porque el usuario pierde confianza en el sistema, lo cual es vital en el correcto funcionamiento de una empresa. Es decir: siempre es preferible echarse la culpa uno mismo, porque mal que mal es bastante difícil que el lenguaje en que está hecho el sistema efectivamente tenga un bug y, admitámoslo, si ocurre alguna falla, lo más probable es que haya sido debido a que nosotros no lo hayamos tomado en cuenta.

Frente a la pregunta acerca de quién había sido el culpable, simplemente hicimos caso omiso: aunque la culpa efectivamente haya sido de alguien en específico, se debe mantener cierto nivel de privacidad para el mismo, y es mejor echarse la culpa como equipo.

Sobre Camilo Sperberg

Es Ingeniero Informático especializado en seguridad y PHP. En su tiempo libre le gusta estudiar nuevas técnicas de programación y escribir. Además, es amigo de todo ser viviente y cree que la tecnocracia es la mejor forma de política.