tres simples preguntas para un buen manejo de excepciones

Se han dicho muchas cosas sobre el manejo correcto de excepciones, pero yo creo que todo se puede resumir en 3 simples preguntas:

Que?
Cuando?
Donde?

que paso y que datos causaron esto?, Esta es probablemente el area donde los desarrolladores tienen mas problema; frecuentemente lo unico que contestan es "que paso?", pero eso no es suficiente; vamos a ver porque:

digamos que tenemos codigo de manejo de errores y...

la aplicacion nos da este mensaje de error (o se guarda en un log): "La informacion del empleado es incorrecta"

el error me dice que paso, pero es demasiado abierto, la descripcion es demasiada vaga, hay muchisimas cosas que podrian estar mal con la informacion del emploeado

Ok, entonces vamos a mejorar el mensaje de error, solo para este ejemplo, digamos que validamos la ciudad; cambiamos el codigo y ahora el error es:

"el valor del campo Ciudad no es valido"

Este mensaje es mucho mejor que el anterior, al menos ya se donde especificamente tengo el problema; la cuestion es que este mensaje de error solo me sirve en el momento en el que sucede, y solo le sirve a la persona/proceso al que le sucedio

Asi que vamos a mejorar aun mas:

"[ILEGIBLE] no es una ciudad valida"

AH!!... ahora se exactamente que paso, y que es lo que lo esta causando, aun si yo solo estuviera leyendo el error en un LOG file, sabria exactamente que paso, lo que es mas, puedo analizar la lista de errores y si veo que este error es muy comun, podria cambiar/mejorar las reglas en la aplicacion basado en la informacion que tengo; tambien me podria dar cuenta de situaciones que si no tuviera esta informacion pues simplemente no sabria, y los usuarios de mi aplicacion "aprenderian" como se tiene que usar la aplicacion, en vez de que se mejorara el proceso, los usuarios tendrian que hacer algo talvez mas lento porque mi aplicacion no da la informacion necesaria

Cuando? siempre debes incluir fecha y hora con cada error

Donde? Esto es casi automatico con esto del stack trace, pero muchas veces el mismo codigo se usa (por ejemplo) desde una aplicacion web y desde un servicio web (estoy haciendo eso mismo ahora) y seria bueno que el mensaje de error tuviera un campo que me indicara de donde se genero el error, si de la aplicacion web o del servicio web

Esto ultimo yo lo he solucionado teniendo un campo adicional en mi tabla de errores llamado "Origen", entonces en la capa mas alta, capturo los errores y lo mando grabar a mi tabla pasando el origen de donde se genero el error, web o servicio web

En resumen, pongan especial atencion al "que?", recuerden que el saber que paso no me dice mucho, los mensajes de error deben contener los datos que causaron el problema, tal como #Empleado, #Producto, propiedad especifica que causo el problema, etc

He visto innumerables veces programadores que tienen que correr una aplicacion varias veces para reproducir el problema, o lo que es peor, el (tristemente) clasico "hableme cuando vea el error otravez!", simplemente porque el log error no contiene informacion que les diga donde es que y que causo el error y que hacer para arreglarlo.

las excepciones deberian ser algo como

el derecho de [Escritura] no se encontro para el empleado [101]

en vez de

No se pudo grabar el registro!

Con la informacion de este ultimo ejemplo que les doy, yo puedo ir a la base de datos inmediatamente y darle derechos de escritura al empleado 101 y se acabo el problema!

Hay un mar de diferencia de un mensaje de error a otro, y ese mar de diferencia es lo que los va a hacer programadores mucho mas productivos a la hora de mantener su mismo software.

El software siempre va a tener bugs, la diferencia es cuanto tiempo les cuesta arreglar un bug cuando estos salen a la vista