A diferencia de lo que muchos piensan, la recomendación de los expertos con relación al manejo de las excepciones, es que deben atenderse al más bajo nivel, o sea, donde se genera la excepción, ya que es ahí, donde tiene sentido la información y es ahí donde se puede manejar adecuadamente. La lógica más simple seria: Analiza si puedes evitar que la excepción deba subir, si no se puede súbela.
A veces por creer que hacemos nuestro código más simple, (que si lo es, pero es un ejemplo de una implementación simplista, en vez de simple), subimos todas las excepciones hasta la capa más alta, en un intento ingenuo de evitarnos escribir mas, y perdemos de vista que colocar bloques Try{} Catch{} en los métodos es lo correcto.
Piensen que la clase no debe estar consciente del entorno, (para evitar que sea cohesiva), entonces: por qué habría de suponer, que arriba de ella en la jerarquía, hay un bloque Try que atenderá la excepción que se están generando dentro de sus métodos?
Clasificación
Las excepciones pueden ser clasificadas de muchas formas, pueden ser agrupadas de acuerdo a su naturaleza, su origen, o por la severidad que representan para nuestra aplicación. Sin embargo cada aplicación puede tener un conjunto de errores particulares, que pueden ser de diferente tipo.
Para simplificar el tema, ubiquemos los mensajes de excepción en dos ámbitos:
Usuario Final: Es una persona que interactúa con el sistema como cliente de nuestra aplicación. No debe recibir mensajes técnicos.
Programador: Es una persona que interactúa con nuestro sistema, al estar codificando, y que durante sus pruebas debería recibir mensajes técnicos.
La confusión con respecto a estos ámbitos se presenta cuando al estar escribiendo el código perdemos de vista para quien estamos programando. Si estamos escribiendo una biblioteca de clase los mensajes deben ser para programadores, si se trata de un Framework, entonces los mensajes que se generan pueden ser para otro programador o para el usuario final, esto va a depender de la forma en que se atiendan las excepciones.
Para poder estar en la misma sintonía tenemos que empezar por organizar los diferentes tipos de error que podemos encontrar.
A continuación les presento algunas:
Excepciones de captura: Son todas aquellas excepciones que se originan por la captura del usuario. Ámbito del usuario.
Excepciones de programación: Son todas las excepciones que se producen por una mala implementación o lógica del programador. Ámbito del programador.
Excepciones heredados: Son excepciones que se reciben de algún componente que internamente usamos. Ámbito del programador.
Excepciones del sistema: Son excepciones que no podemos prevenir, por ejemplo se pierde la red, o error de escritura en memoria o en disco duro.
El problema con todo esto, es que el manejo de excepciones, su categorización o clasificación o la identificación del nivel de severidad, puede resultar muy subjetivo; o sea puede ser algo completamente interpretativo; lo que para un proyecto puede ser algo que no afecte su flujo, para otro podría ser algo, que deba impedir que el sistema continúe su operación.
Visto de esta manera podemos empezar por decir que Throw New Exception por sí solo no es una buena práctica, hay que aplicar algún criterio de estandarización, para que lo que podría resultar manejado de diferente forma por cada programador, se organice y establezca un patrón uniforme al momento de atender estas excepciones.
Analicemos según los tipos.
Las excepciones de captura, si deben subir hasta la capa de presentación, ya que es importante que nuestro usuario se entere de lo que impide continuar.
Las excepciones de programación se deben atender a nivel del código donde se origino, para que podamos implementar algún mecanismo de registro de estos y posteriormente, retroalimentar a quien se encargue del mantenimiento del sistema.
Las excepciones heredadas, pueden ser mensajes en otro idioma o técnicos, por lo tanto este tipo de excepciones, deberían analizarse y de ser necesario traducirse, al idioma adecuado o a palabras que no sean técnicas. Esto nos ubica en el ámbito del receptor del mensaje, puede ser un programador o un usuario.
Las del sistema siempre deben ser manejadas por nuestra aplicación, para impedir que la aplicación explote ante los ojos de nuestro cliente.
Entonces cuando se debe emplear Throw New Exception?
Se recomienda usarlo cuando nosotros hemos detectado un error en el proceso con una severidad tal, que no se debería continuar operando, siempre y cuando no lo podamos o no lo debamos contenerlo en ese nivel. Esto quiere decir que si el error es un estado de excepción en nuestro programa, debe ser tratado como tal. Pero nunca debe ser una excepción que atrapamos en algún catch. Por que se pierde el motivo real que origino la excepción.
Alternativas
Si determinamos que la excepción debe subir de nivel por que no le corresponde a esta bloque de código lidiar con la situación, entonces se debe emplear la palabra Throw, ya que si usamos Throw ex, eliminamos la pila de seguimiento.
Costo
Cada vez que usamos el Throw New Exception se agregan apuntadores a la pila, lo que representa un costo en memoria; además al tener que atender la creación de la instancia de la excepción usando Reflection, se debe pagar el precio el tiempo de procesador, todo esto adicional a lo que de por si debe hacer nuestra aplicación.
En conclusión
Las excepciones deben manejarse al más bajo nivel, para que sea correcto y no represente ningún costo adicional; se debe contar con un mecanismo que facilite la persistencia de la excepción en algún lugar, y por ultimo debemos usar el Throw New Excepción con responsabilidad.
No hay comentarios:
Publicar un comentario