Pendiende de revision y de ser pasado a ingles. Solo como recordatorio.
NoesisEngine incorpora un mecanismo de gestion de errores que emplea excepciones en aquellas compilaciones de trabajo normal y emplea mecanismos menos sofisticados para aquellas compilaciones en las que la sobrecarga que conllevan las excepciones no son admisibles.
Ninguna de las funciones de la API de NoesisEngine emplea un valor devuelto (bool, ErrCode) para notificar de un error interno de la API. El comportamiento normal de una funcion es que funcione correctamente (y lo hara asi la gran mayoria de las veces) y por tanto no es necesario chequear frente a un codigo de error devuelto. Esto deja un codigo mucho mas limpio, sin montones de ifs chequeando errores.
En las versiones de desarrollo donde las funciones generan excepciones hay que tener en cuenta los siguientes aspectos importante:
- Una funcion generara una exception cuando no pueda llevar a cabo lo que su nombre debe expresar de una manera clara (por ejemplo, FileOpen() debera abrir un fichero si no puede, notiticara mediante una excepcion)
- Cualquier excepcion generada por una funcion se considera un Bug y debe ser arreglado lo antes posible. Si la excepcion vino de un codigo con bug (como por ejemplo un acceso de memoria fuera de rango) se arreglara. Si la excepcion se produjo por otro motivo, la API debe dar la funcionalidad adecuada para que la excepcion pueda ser evitada (Por ejemplo, hacer un FileOpen() de un fichero que no exixte, reportara error. La API debe proporcionar el correspondiente ExistFile() que nos indica si un fichero exixte o no. Hay que decir que no es necesario llamar a la funcion ExistFile() siempre antes de un OpenFile() (si no, esta ya lo haria automaticamente) solo en aquellos casos en los que el fichero que se intenta abrir puede que no exista)
- Aquellas funciones que por cuestiones de eficiencia no generen excepciones empezaran su nombre por Try. En estas funciones se permite devolver un Bool o un ErrCode que informe sobre el estado de la operacion (Por ejemplo, si fuera muy ineficiente (habria que demostrarlo) llamas a ExistFile y OpenFile, la API expondria una funcion del tipo TryOpenFile que nunca devolveria excepcion con respecto a la operacion que se espera que realice con el nombre que tiene. Por supuesto puede generar excepciones debido a otros motivos. Por ejemplo TryFileOpen podria devolver una excepcion en caso de quedarse sin memoria)
- Como la generacion de excepciones se considera un bug no se debe usar zonas de codigo que absorban silenciosamente excepciones. Las excepciones generadas deben ser siempre notificadas claramente para que puedan ser arregladas. En algunas circustancias especiales, se permite capturar excepciones, por ejemplo, una Tool para evitar que el usuario pierda el trabajo que no esta grabado, puede dar la oportunidad de grabar los datos antes de propagar el error hacia fuera
- Debido a las caracteristicas del sistema de excepciones descrito arriba. El modelo de gestion de errores de NoesisEngine puede prescindir de excepciones en aquellas compilaciones especialmente criticas y convertir la generacion de errores en un exit(0) (o incluso una excepcion pero sin desenrrollado de pila). Esto deja un codigo totalmente libre de la pequena ineficiencia que un sistema de excepciones incorpora.
- Queda por documentar el conjunto de marcas definidas para el sistema de errores de NoesisEngine. Hace falta funcionalidad para lanzar un error, capturar un error, refinar un error (anadir informacion extra al capturarlo y volverlo a lanzar), convertir un error a assert, convertir un error a warning.