## Excepciones en Tiempo de Ejecución -- La Controversia

Como el lenguaje Java no requiere que los métodos capturen o especifiquen las excepciones en tiempo de ejecución, es una tentación para los programadores escribir código que lance sólo excepciones de tiempo de ejecución o hacer que todas sus subclases de excepciones hereden de la clase RuntimeException. Estos atajos de programación permiten a los programadores escribir código Java sin preocuparse por los consiguientes:

    InputFile.java:8: Warning: Exception java.io.FileNotFoundException must be caught,
    or it must be declared in throws clause of this method.
            fis = new FileInputStream(filename);
                  ^

errores del compilador y sin preocuparse por especificar o capturar ninguna excepción. Mientras esta forma parece conveniente para los programadores, esquiva los requerimientos de Java de capturar o especificar y pueden causar problemas a los programadores que utilicen tus clases.

¿Por qué decidieron los diseñadores de Java forzar a un método a especifiar todas las excepciones chequeadas no capturadas que pueden ser lanzadas dentro de su ámbito? Como cualquier excepción que pueda ser lanzada por un método es realmente una parte del interface de programación público del método: los llamadores de un método deben conocer las excepciones que el método puede lanzar para poder decidir concienzuda e inteligentemente qué hacer con estas excepciones. Las excepciones que un método puede lanzar son como una parte del interface de programación del método como sus parámetros y devuelven un valor.

La siguiente pregunta podría ser: " Bien ¿Si es bueno deocumentar el API de un método incluyendo las excepciones que pueda lanzar, por qué no especificar también las excepciones de tiempo de ejecución?".

Las excepciones de tiempo de ejecución representan problemas que son detectados por el sistema de ejecución. Esto incluye excepciones aritméticas (como la división por cero), excepciones de punteros (como intentar acceder a un objeto con un refetencia nula), y las excepciones de indexación (como intentar acceder a un elememto de un array a través de un índice demasiado grande o demasiado pequeño).

Las excepciones de tiempo de ejecución pueden ocurrir en cualquier lugar del programa y en un programa típico pueden ser muy numerosas. Típicamente, el coste del chequeo de las excepciones de tiempo de ejecución excede de los beneficios de capturarlas o especificarlas. Así el compilador no requiere que se capturen o especifiquen las excepciones de tiempo de ejecución, pero se puede hacer.

Las excepciones chequeadas representan información útil sobre la operación legalmente especificada sobre la que el llamador podría no tener control y el llamador necesita estar informado sobre ella -- por ejemplo, el sistema de ficheros está lleno, o el ordenador remoto ha cerrado la conexión, o los permisos de acceso no permiten esta acción.

¿Qué se consigue si se lanza una excepción RuntimeException o se crea una subclase de RuntimeException sólo porque no se quiere especificarla? Simplemente, se obtiene la posibilidad de lanzar una excepción sin especificar lo que se está haciendo. En otras palabras, es una forma de evitar la documentación de las excepciones que puede lanzar un método. ¿Cuándo es bueno esto? Bien, ¿cuándo es bueno evitar la documentación sobre el comportamiento de los métodos? La respuesta es "NUNCA".

Reglas del Pulgar:

- Se puede detectar y lanzar una excepción de tiempo de ejecución cuando se encuentra un error en la máquina virtual, sin embargo, es más sencillo dejar que la máquina virtual lo detecte y lo lance. Normalmente, los métodos que escribas lanzarán excepciones del tipo Exception, no del tipo RuntimeException.
- De forma similar, puedes crear una subclase de RuntimeException cuando estas creando un error en la máquina virtual (que probablemente no lo hará), De otro modo utilizará la clase Exception.
- No lances una excepción en tiempo de ejecución o crees una subclase de RuntimeException simplemente porque no quieres preocuparte de especificarla.

Ozito