tipos que propagacion personalizadas lista jerarquia excepciones java exception

que - tipos de excepciones en java



¿Cuándo debo crear una nueva clase de excepción? (10)

Me doy cuenta de que varias clases de excepción de Java solo difieren en el nombre de la clase y no agregan ninguna funcionalidad nueva. La mayoría de las excepciones, por ejemplo, parecen anular Exception() or Exception(String message) . Esto va en contra de los principios de la herencia, es decir: heredar para agregar una nueva funcionalidad.

¿Cuáles son algunas buenas razones para crear una nueva clase de excepción?

Crear una excepción para cualquier tipo es realmente tonto. Tal vez debería crear una excepción para una capa diferente (DAO, Servicio, etc.) o una acción diferente (crear registro, duplicar registro, etc.).

En este caso, la funcionalidad que agrega la herencia está relacionada con la declaración catch, que puede distinguirse por tipo. Normalmente, la distinción entre subclases por tipo se considera una mala práctica, pero el manejo de excepciones es, bueno, una excepción.

Definitivamente conduce a situaciones extrañas (como varias declaraciones de captura que tienen la misma lógica) que se esperaría cuando las cosas se distinguen por tipo, pero eso es una limitación del lenguaje.

Es una mala forma simplemente detectar una excepción, ya que no solo no sabrá de dónde provino, sino que también se estará impidiendo manejar los errores correctamente cuando ocurren. Si acaba de detectar cualquier excepción de tipo y la maneja de la misma manera genérica, puede estar ocultando otros problemas en su software, o incluso introduciendo otros nuevos. Así que, técnicamente hablando, la excepción de subclases agrega funcionalidad nueva.

Este cambio de nombre se produce para eliminar la ambigüedad wrt. El error que se ha producido. p.ej

Foo getFoo() throws FooNotFoundException

será explícito al indicar que no se puede encontrar un Foo , a diferencia de (¿qué?) algún estado ilegal, o un error de conexión de base de datos o similar, y puede elegir codificar (o no) para ese error en particular . Si elige lanzar una excepción más genérica, es menos claro (programáticamente) lo que ocurrió.

Las excepciones son un caso especial. En su caso, la herencia no es agregar una nueva funcionalidad, sino agregar nuevas clases de errores. Esto permite que su código detecte tipos particulares de errores mientras ignora otros.

Digamos que estás escribiendo un gran proyecto. Tiene un componente de datos y un componente de visualización. Ambos pueden fallar de varias maneras, y usted quiere lanzar excepciones para estos fallos. Sin embargo, al componente Display no le importan las excepciones que surgen del componente Data y viceversa. Si todas las clases solo lanzaran Exception , no habría manera de averiguar de dónde vino la excepción. Sin embargo, si subclasifica Exception con DataException y GraphicsException , aunque no agreguen nueva funcionalidad, ahora puede lanzar y capturar esos tipos particulares de excepciones, es decir, un componente de gráficos puede detectar GraphicsException y no tener que lidiar con las excepciones de datos.

Puede capturar excepciones por tipo, y tener una excepción de un tipo en particular que de otra manera es idéntica a la clase de excepción base le permite ser preciso en su manejo de excepciones.

Yo diría que agrega nueva funcionalidad directamente al aumentar la especificidad del código de manejo de excepciones.

Recomendaría leer todo, o la mayoría, del Capítulo 9 de Effective Java . Especialmente el Artículo 60: "Favorecer el uso de excepciones estándar" y el Artículo 61: "Lanzar excepciones apropiadas a la abstracción".

EDITAR 1: O Artículos 42 y 43 en la primera edición.

Si necesita o desea diferenciar la situación de error particular de otros errores en el código , entonces tiene sentido subclasificar la excepción apropiada. NO debe tener que mirar el mensaje de error para determinar qué salió mal, solo para ojos humanos.

También tenga en cuenta que una excepción con un nombre adecuado puede ser suficiente para que los mantenedores puedan deducir qué fue lo que no funcionó al tener que diagnosticar un seguimiento de pila. Un ejemplo típico es ArrayOutOfBoundsException.

Usted agrega una nueva clase de excepción cuando un usuario de su API podría necesitar capturarla condicionalmente (o, para las excepciones verificadas, especifique diferentes tipos específicos en una throws ).

Utilice un nuevo tipo de excepción cuando desee proporcionar manejo de errores para una determinada condición. Eche un vistazo a la excepción java.io.IOException y verá las siguientes subclases:

ChangedCharSetException CharacterCodingException CharConversionException ClosedChannelException EOFException FileLockInterruptionException FileNotFoundException FilerException HttpRetryException IIOException InterruptedIOException InvalidPropertiesFormatException JMXProviderException JMXServerErrorException MalformedURLException ObjectStreamException ProtocolException RemoteException SaslException SocketException SSLException SyncFailedException UnknownHostException UnknownServiceException UnsupportedDataTypeException UnsupportedEncodingException UTFDataFormatException ZipException

Digamos que desea leer un archivo, podría obtener una excepción IOException genérica, una excepción FileNotFoundException y una excepción EOFException. Es posible que desee manejar cada uno de esos casos de manera diferente. Si todo lo que tenía era IOException, tendría que hacer algo como mirar el mensaje de error y luego hacer una declaración if / else para averiguar cuál era el error real para que pueda mostrar un mensaje sensible al usuario. Con una jerarquía de excepciones, puede lidiar con esas situaciones mucho más fácilmente.