salida - propagacion de excepciones en java
Mejores prácticas de Java al lanzar excepciones: lanzar excepciones principales de Java (5)
Absolutamente tiene sentido reutilizar las clases de Exception cuando describen razonablemente el escenario que causó que se lanzara la excepción.
En lugar de lanzar una new Exception("Some message", maybeSomeCause) , lo que significa que todas las personas que llaman a mi método tendrán que detectar Exception (que puede incluir RuntimeExceptions), me gustaría lanzar un tipo de excepción más específico cuando se produce un problema .
Puedo crear mis propios tipos de excepción que extienden la excepción u otro tipo de excepción, pero tengo curiosidad por saber si es una buena idea reutilizar algunas excepciones que vienen con el lenguaje Java central, como:
- Argumento de excepción ilegal
- ExcepcionalOperaciónExcepción
- IOException
- ¿Otros?
¿Hay otros que me faltan? Encontré una lista básica de las excepciones ''centrales'' aquí: http://rymden.nu/exceptions.html , con explicaciones humusales.
¡Gracias!
Editar:
¿Hay una buena lista de excepciones ''centrales''?
Lista hasta ahora:
La mayoría de las excepciones centrales son demasiado especializadas para ser utilizadas directamente, a menos que esté duplicando la funcionalidad existente en las librerías básicas. Por ejemplo, probablemente nunca necesitará crear una instancia de UnknownHostException ; Si la resolución del host falla, el método InetAddress o SocketFactory que llamó ya habría creado y lanzado la excepción.
Las únicas excepciones que se encuentran generalmente utilizables son IOException , IllegalArgumentException , IllegalStateException y UnsupportedOperationException .
IOException : todos los problemas con las interfaces, las redes y el acceso al disco duro se incluyen en este. Si está escribiendo un código para acceder a datos o hardware externos, debe usar esto. Por ejemplo, si está implementando una API para acceder a cierto tipo de dispositivo de red, puede crear una subclase MyDeviceException que se MyDeviceException cuando el dispositivo devuelva un estado de error o haga algo extraño. También hay algunos casos en los que desea capturar una IOException de una o más llamadas de biblioteca de bajo nivel y envolverla en otra IOException con un mensaje de nivel superior, como una verificación de conectividad que arroja una excepción "Dispositivo no disponible" causada por una Excepción de "solicitud agotada".
IllegalArgumentException : cualquier comprobación de parámetros debe lanzar esto. Por ejemplo, un entero negativo para un parámetro de tamaño, o un null inesperado. Esta es una excepción sin marcar, pero recomiendo documentarla de todos modos para que el método sea más claro. Puedes encontrar muchos ejemplos en las librerías básicas.
IllegalStateException : puede usar esto cuando los parámetros del método son válidos, pero algunos datos internos o la funcionalidad requerida por el método no están disponibles, y no hay una excepción comprobada más apropiada (como IOException ). A menudo es mejor diseñar cosas para que esto no sea necesario.
UnsupportedOperationException : si UnsupportedOperationException una subclase de algo y uno de los métodos de superclase no es válido desde el punto de vista conceptual, invalídelo y lance uno de estos. Guava usa esto para sus clases de colección inmutables , ya que las interfaces de colección de Java no están diseñadas para soportar la inmutabilidad. Esto tiende a ser un signo de mal diseño en la superclase. No lo use si solo hacer nada o devolver nulo / vacío sería un resultado apropiado y sorprendente.
Las listas proporcionadas en su pregunta no son muy útiles como material de referencia rápida, y la mayoría de las descripciones en los documentos de desarrollo me parecen crípticas.
No he encontrado ninguna lista corta de las excepciones incorporadas más reutilizables. He hecho todo lo posible para crear uno a continuación, pero estoy seguro de que está lejos de ser perfecto.
enlace github gist (o vea el contenido actual a continuación)
Lista de excepciones incorporadas potencialmente reutilizables
organizado por utilidad estimada
Argumento de excepción ilegal
Se lanza para indicar que un método ha pasado un argumento ilegal o inapropiado.
IndexOutOfBoundsException
Se lanza para indicar que un índice de algún tipo (como un conjunto, una cadena o un vector) está fuera de rango.
AritméticaExcepción
Se arroja cuando la operación matemática solicitada no es sensorial o imposible. Ejemplo: int x = 1/0 ;
IllegalStateException
La aplicación no se encuentra en un estado apropiado para la operación solicitada. Ejemplo: intentar guardar antes de cargar o crear el archivo.
DataFormatException
Tira esto cuando hayas recibido datos formateados incorrectamente. ejemplo: MyClass.applyJSONString("{non:sense,all,garbled=definitely.not;json{{{")
TimeoutException
Tira esto si algo te tomó mucho tiempo y te estás rindiendo.
KeySelectorException
Creo que tiene sentido lanzar esto si intentas buscar un objeto con una clave y no se encontró o la clave no es válida, pero realmente no entiendo la documentación del desarrollador.
ejemplo: myDataStructure.get("lookup_key"); cuando lookup_key no está en la estructura de datos.
IOException
¿Tienes algún problema para leer / escribir? Tira esta excepción.
ScriptException
¿Ejecutar una secuencia de comandos de alguna forma y encontró un problema con ella (no E / S o análisis)? Tira esta excepción.
GeneralSecurityException
Tira esto si encuentras un problema relacionado con la seguridad.
Excepción en tiempo de ejecución
Use esto para algunos errores de tiempo de ejecución que no encajan bien en ninguna otra categoría.
Sí, es muy bueno hacer eso. De hecho, incluso está escrito en Effective Java, 2ª ed. Vea el ítem 60 en la página 248: "Favorecer el uso de excepciones estándar"
Reutilizar excepciones preexistentes tiene varios beneficios. El principal de ellos es que hace que su API sea más fácil de aprender y usar, ya que coincide con las convenciones establecidas con las que los programadores ya están familiarizados. Un segundo es que los programas que usan su API son más fáciles de leer porque no están llenos de excepciones desconocidas. Por último (y menos), menos clases de excepción significan una huella de memoria más pequeña y menos tiempo dedicado a cargar clases.
Si los usuarios de su código necesitan hacer cosas diferentes en dos excepciones diferentes, entonces esos deben ser tipos de excepción distintos. Dicho esto, las excepciones de JDK cubren la mayoría de las excepciones de "error de programador": si se IllegalArgumentException una excepción IllegalArgumentException , por ejemplo, eso indica un error de programación, no algo que deba manejarse en tiempo de ejecución.