Este es un tema un tanto complejo, por que muchos programadores consideran que usar un try - catch es un control de excepciones, y eso no lo es, realmente un programa nunca debería caer en una excepción del tipo try - catch, ¿Por que?, por que el hecho de que caiga ahí quiere decir que existe algo que no estamos realizando de la manera correcta.
Atrapar una excepción, nos permite evitar que un programa colapse, por que algo ocurrió que esta fuera del ámbito de nuestro programa, algo que nosotros no controlamos de un inicio (siempre es mejor controlar una excepción de un inicio a atraparla, por que entonces nuestra lógica se altera).
Sin embargo eso tampoco es un control de excepciones, no basta con solo atraparlas, lo que se debe hacer es decir como debe reaccionar el proceso en caso de que estas ocurran.
Un flujo complejo que se detiene por una excepción y que deja los datos a medio procesar puede ser un gran dolor de cabeza, me dirán, existen las transacciones que permiten que se efectué un todo o nada, si existen y es algo de lo que hablaremos después, pero hay casos en los que por limitaciones de recursos (no olviden estamos en la era del big data) es muy complicado el uso de una transacción.
Por ello se deben implementar medios para realmente controlar una excepción, algo mas allá de una linea que en muchos de los casos no dice nada.
Peor aun hay quien enmascara una excepción con un error del tipo "Ha ocurrido un error consulte a su administrador del sistema", pero no existe información por ningún lado de como ocurrió el error, de por que ocurrió, encontrar una aguja en un pajar es mucho mas fácil.
Entonces ¿Como debemos construir una excepción?, bueno, debemos seguir una serie de reglas en su construcción, reglas que nos facilitaran mucho la vida.
Atrapar una excepción, nos permite evitar que un programa colapse, por que algo ocurrió que esta fuera del ámbito de nuestro programa, algo que nosotros no controlamos de un inicio (siempre es mejor controlar una excepción de un inicio a atraparla, por que entonces nuestra lógica se altera).
Sin embargo eso tampoco es un control de excepciones, no basta con solo atraparlas, lo que se debe hacer es decir como debe reaccionar el proceso en caso de que estas ocurran.
Un flujo complejo que se detiene por una excepción y que deja los datos a medio procesar puede ser un gran dolor de cabeza, me dirán, existen las transacciones que permiten que se efectué un todo o nada, si existen y es algo de lo que hablaremos después, pero hay casos en los que por limitaciones de recursos (no olviden estamos en la era del big data) es muy complicado el uso de una transacción.
Por ello se deben implementar medios para realmente controlar una excepción, algo mas allá de una linea que en muchos de los casos no dice nada.
Peor aun hay quien enmascara una excepción con un error del tipo "Ha ocurrido un error consulte a su administrador del sistema", pero no existe información por ningún lado de como ocurrió el error, de por que ocurrió, encontrar una aguja en un pajar es mucho mas fácil.
Entonces ¿Como debemos construir una excepción?, bueno, debemos seguir una serie de reglas en su construcción, reglas que nos facilitaran mucho la vida.
- Debemos buscar controlar las excepciones desde codificación, para ya tener una alternativa en el proceso de que hacer en caso de que fallen.
- Si se da una excepción, cosa que no podemos evitar esta nos debe dar la información suficiente para reproducir el error (método, variables, etc).
- Es conveniente que conozcamos el flujo de nuestro proceso para tener un plan de contingencia en caso de que una excepción nos cause algún problema, esto se debe evaluar desde una etapa de diseño, generar un plan de contingencia en producción no es buena idea.
- Si no se desea ser alarmista con el cliente (por imagen) la información de como reproducir el problema se debe almacenar en algún sitio aparte, no solo enviar el mensaje de "un error a ocurrido", si por imagen no se quiere mostrar el error como tal, entonces por imagen deben resolverlo lo antes posible, y si no tienen idea de que paso, esto se convertirá en insatisfacción rápidamente, somos una herramienta para mejorar procesos, no podemos comernos el tiempo del usuario tratando de solucionar errores en los mismos.
Felices lineas
Carlos
No hay comentarios.:
Publicar un comentario