Cuando dise�es un paquete de clases java que colabore para proporcionar alguna funci�n �til a sus usuarios, deber�s trabajar duro para asegurarte de que las clases interactuan correctamente y que sus interfaces son f�ciles de entender y utilizar.Debr�as estar mucho tiempo pensando sobre ello y dise�ar las excepciones que esas clases pueden lanzar.
Supon que est�s escribiendo una clase con una lista enlazada que est�s pensando en distribuir como freeware. Entre otros m�todos la clase deber�a soportar estos.
- objectAt(int n)
- Devuelve el objeto en la posici�n nde la lista.
- firstObject()
- Devuelve el primer objeto de la lista.
- indexOf(Object o)
- Busca el Objeto especificado en la lista y devuelve su posici�n en ella.
��Qu� puede ir mal?
Como muchos programadores utilizar�n tu clase de lista enlazada, puedes estar seguro de que muchos de ellos la utilizar�n mal o abusar�n de los m�todos de la clase. Tambi�n, alguna llamada legitima a los m�todos de la clase podr�a dar alg�n resultado indefinido. No importa, con respecto a los errores, querr�a que tu clase sea lo m�s robusta posible, para hacer algo razonable con los errores, y comunicar los errores al programa llamador. Sin embargo, no puedes anticipar como quiere cada usuario de sus clase enlazada que se comporten sus objetos ante la adversidad. Por eso, lo mejor que puedes hacer cuando ocurre un error es lanzar una excepci�n.
Cada uno de los m�todos soportados por la lista enlazada podr�a lanzar una excepci�n bajo ciertas condiciones, y cada uno podr�a lanzar un tipo diferente de excepci�n. Por ejemplo.
- objectAt()
- lanzar� una excepci�n si se pasa un entero al m�todo que sea menor que 0 o mayor que el n�mero de objetos que hay realmente en la lista.
- firstObject()
- lanzar� una excepci�n si la lista no contiene objetos.
- indexOf()
- lanzar� una excepci�n si el objeto pasado al m�todo no est� en la lista.
Pero �qu� tipo de excepci�n deber�a lanzar cada m�todo? �Deber�a ser una excepci�n porporcionada por el entorno de desarrollo de Java? O �Deber�an ser excepciones propias?
�Elegir el Tipo de Excepci�n Lanzada
Trant�ndose de la elecci�n del tipo de excepci�n a lanzar, tienes dos opciones.
- Utilizar una escrita por otra persona. Por ejemplo, el entorno de desarrollo de Java proporciona muchas clases de excepciones que podr�as utilizar.
- Escribirlas tu mismo.
Necesitar�s escribir tus propias clases de excepciones si respondes "Si" a alguna de las siguentes preguntas. Si no es as�, probablemente podr�s utilizar alguna excepci�n ya escrita.
- �Necesitas un tipo de excepci�n que no est� representada por lo existentes en el entorno de desarrollo de Java?
- �Ayudar�a a sus usuarios si pudieran diferenciar sus excepciones de las otras lanzadas por clases escritas por por otros vendedores?
- �Lanza el c�digo m�s una excepci�n relacionada?
- Si utilizas excepciones de otros, �Podr�n sus usuarios tener acceso a estas excepciones? Una pregunta similar es "�Deber�a tu paquete ser independiente y auto-contenedor?"
La clase de lista enlazada puede lanzar varias excepciones, y ser�a conveniente poder capturar todas las excepciones lanzadas por la lista enlaza con un manejador. Si planeas distribuir la lista enlazada en un paquete, todo el c�digo relacionado debe empaquetarse junto. As� para la lista enlazada, deber�as crear tu propio �rbol de clases de excepciones.
El siguiente diagrama ilustra una posibilidad del �rbol de clases para su lista enlazada.
LinkedListException es la clase padre de todas las posibles excepciones que pueden ser lanzadas por la clase de la lista enlazada, Los usuarios de esta clase pueden escribir un s�lo manejador de excepciones para manejarlas todas con una sentencia catch como esta.
catch (LinkedListException) {
. . .
}
O, podr�ia escribir manejadores m�s especializados para cada una de las subclases de LinkedListException.
�Elegir una Superclase
El diagrama anterior no indica la superclase de la clase LinkedListException. Como ya sabes, las excepciones de Java deben ser ejemplares de la clase Throwable o de sus subclases.
Por eso podr�a tentarte hacer LinkedListException como una subclase de la clase Throwable.
Sin embargo, el paquete java.lang proporciona dos clases Throwable que dividen los tipos de problemas que pueden ocurrir en un programa java: Errores y Excepci�n. La mayor�a de los applets y de las aplicaciones que escribes lanzan objetos que son Excepciones. (Los errores est�n reservados para problemas m�s serios que pueden ocurrir en el sistema.)
Teor�camente, cualquier subclase de Exception podr�a ser utilizada como padre de la clase LinkedListException. Sin embargo, un r�pido examen de esas clases muestra que o son demasiado especializadas o no est�n relacionadas con LinkedListException para ser apropiadas.
Asi que el padre de la clase LinkedListException deber�a ser Exception.
Como las excepciones en tiempo de ejecuci�n no tienen por qu� ser especificadas en la clausula throws de un m�todo, muchos desarrolladores de paquetes se preguntan.
"�No es m�s sencillo hacer que todas mis excepciones sean heredadas de Runtime Exception?" La respuesta a esta pregunta con m�s detalle en Excepciones en Tiempo de Ejecuci�n -- La Controversia. La l�nea inferior dice que no deber�as utilizar subclases de RuntimeException en tus clases a menos que tus excepciones sean realmente en tiempo de ejecuci�n! Para la mayor�a de nosotros, esto significa "NO, tus excepciones no deben descender de la clase RuntimeException."
�Convenciones de Nombres
Es una buena pr�ctica a�adir la palabra "Exception" al final del nombre de todas las clases heredadas (directa o indirectamente) de la clase Exception. De forma similar, los nombres de las clases que se hereden desde la clase Error deber�an terminar con la palabra "Error".