Ingenieria del caos

En cualquier curso de algoritmia o programación, bien en las universidades o en otro tipo de estudios se introduce la excepción como mecanismo básico de comunicación de errores en un entorno orientado a objetos. Sin embargo, quizá no sé explique o no se entienda por parte de los alumnos las implicaciones de usarlas correctamente en contraposición a otros métodos como la devolución de códigos de error.

Hay una serie de consecuencias importantes que podríamos resumir en:

• Unifican el método de comunicación de error. Deben ser utilizadas para comunicar errores en cualquier situación donde sea conveniente y no deben ser mezcladas con otro tipo de métodos, como los citados códigos de error. Un método de comunicación de errores siempre es mucho mejor que dos.

• Permiten controlar el error lejos del punto de fallo.  Utilizando códigos de error este control siempre está cerca del fallo lo que aumenta las posibilidades de elección. La excepción puede ir “subiendo” en la pila de llamadas.

• El código se torna más robusto, el tratamiento de errores puede centralizarse o dividirse según decida el programador. Comunicar errores con códigos de error obliga, evidentemente, a utilizar sentencias condiciones (IF) para comprobar el éxito o fallo de la llamada. Además de aumentar la complejidad del código obliga a tratar el problema ahí mientras que con las excepciones podemos agrupar el tratamiento en el “catch” o en una parte superior de la pila de llamadas.

• Los códigos de error pueden ser ignorados con facilidad. Las excepciones sin embargo, rompen la ejecución normal del programa lo que hace imposible que sean ignoradas. Partiendo de que cuantos más errores sean detectados durante la fase de testing mejor será el código generado, queda claro que las excepciones facilitan esta detección.

Vamos, visto lo visto, cada vez que salte una excepción alégrate. En tu próxima versión no saltará