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:
|