por Sergio Montoro Ten, 4 julio 05

Siempre he sentido curiosidad por saber cual será el próximo paradigma de programación. A uno siempre le gustaría anticiparse y aportar su granito de area. De modo que propongo una nueva filosofía llamada Programación Orientada a Errores. Está basada en algo muy simple: ¿qué porcentaje de código de un programa típico es control de errores? De hecho hubo que inventar las excepciones porque gran parte de la complejidad ciclomática de los programas era debida a la verificación de los valores de retorno de funciones.

La POE se basaría en tres principios:

1. Crear patrones de diseño para la creación y manejo de excepciones.
Nos hemos acostumbrado a que las excepciones son una forma de estructuras de control. Porque así es en Java, Ada, C++ y muchos otros lenguajes. Pero este no es el único modelo posible. Eiffel trata las excepciones más como condiciones verdaderamente anómalas e impredecibles. El principio básico de Eiffel es que una subrutina debe necesariamente tener éxito o fallar. Las excepciones se usan en Eiffel para señalizar que un procedimiento no cumplió con su contrato de servicio. Las excepciones no figuran en la signatura del método. Las excepciones se representan mediante cadenas o enteros y no existe una clase excepción.

2. Crear herramientas y/o lenguajes de programación que permitiesen separar el código de control del código de ejecución. Por ejemplo, ocultando selectivamente trozos de código para leer el resto con más claridad, etc.

3. Crear librerías estándar para generar logs y registros de auditoría.

Hay pues cuatro grandes áreas abiertas:

1. Cómo definir una política de creación de excepciones y su manejo.
Cuantas clases diferentes de excepciones es conveniente crear. Cuando deberían lanzarse. Que parte del programa debería ser responsable de su gestión.
Por ejemplo, en Java no existe una diferencia clara entre 3 tipos de excepciones: las que señalizan un fallo (puntero nulo), las que indican un resultado (fin de fichero) y las que monitorizan una condición (tamaño de fichero de entrada demasiado grande). En cambio Java sí distingue entre dos tipos de excepciones: las que deben ser necesariamente checkeadas y las que no.

2. Cerrar un estándar de pre-condiciones y post-condiciones.
Incluido dentro del lenguaje y sensible a si el programa está en modo debug o explotación.

3. Cómo crear ficheros de log.
Cómo ajustar la cantidad de mensajes que se vuelcan según su severidad. Cómo volcar los logs de ejecución de programas multi-hilo como un servidor web.

4. Cómo crear registros de auditoría útiles.
La auditoría es diferente de los logs. En los logs se busca conocer todos los detalles sobre la ejecución de un proceso. La auditoría consiste en saber qué usuario realizó que operaciones concretas de alto nivel y cuando.

Quienes no están familiarizados con el diseño de sistemas complejos tienden a diseñar medidas ad-hoc para recuperarse de excepciones. Es la tarea del buen arquitecto de sistemas discriminar los distintos tipos de situaciones anómalas y crear una política general de tratamiento. No es lo mismo que un usuario no pueda retirar dinero porque su saldo está a cero que tener caída la conexión con la base de datos.

Una posible táctica de diseño es identificar comunidades de riesgo. Una comunidad de riesgo es un conjunto de componentes a través de los cuales un error puede propagarse de forma transitiva.

Para mi, otro gran problema abierto es cómo cerrar los objetos que tienes abiertos en el caso de tener que salir de forma precipitada de un proceso. El caso clásico es liberar el comando SQL y cerrar la conexión si se produce un error mientras está recorriendo un recordset.

Si miramos un poco más hacia el futuro, las nuevas técnicas de computación distribuida (Grid) traen incluso nuevos desafíos derivados de controlar un errores asíncronos en componentes heterogéneos, remotos y distribuidos.