excepciones - java throw exception example

¿Envolviendo una excepción marcada en una excepción no verificada en Java?

Question

Tengo este método de fábrica en Java:

public static Properties getConfigFactory() throws ClassNotFoundException, IOException {
if (config == null) {
InputStream in = Class.forName(PACKAGE_NAME).getResourceAsStream(CONFIG_PROP);
config = new Properties();
config.load(in);
}
return config;
}

Y quiero transformar las dos excepciones comprobadas en excepciones sin marcar. ¿Cuál es la mejor manera de hacerlo?

¿Debería capturar la excepción y lanzar una nueva RuntimeException usando la excepción atrapada como la excepción interna?

¿Hay una mejor manera de hacer esto o debería intentar hacer esto en primer lugar?

EDITAR:
Solo para aclarar. Estas excepciones serán fatales, ya que el archivo de configuración es esencialmente para el funcionamiento del programa y todas las excepciones serán capturadas y registradas en el nivel superior de mi programa.

Mi propósito es evitar una excepción innecesaria de lanzamientos, excepción añadida a la firma de todos los métodos que llaman a mi fábrica.

Answer 1

Lo estás haciendo de la manera correcta.

Para permitir que las excepciones controladas pasen sin ser verificadas, debe envolverlas en excepciones no verificadas.

Solo recuerde, las excepciones se verifican por un motivo.

Answer 2

Si desea evitar demasiadas try - catch , capture ambas excepciones en la fábrica y trátelas allí. Quizás devuelva una implementación predeterminada.

Tienes que manejar las excepciones, aquí o en otro lugar.

Y como se trata de una fábrica, creo que es mejor que estas excepciones se manejen en la propia fábrica (el mismo método o método diferente) y que se devuelva una implementación predeterminada.

De todos modos, la persona que llama (función comercial) no tendrá idea de lo que se debe hacer cuando encuentre una ClassNotFoundException .

Answer 3

Una RuntimeException debe usarse solo cuando el cliente no puede recuperarse de cualquier problema. Ocasionalmente es apropiado hacer lo que está diciendo, pero más a menudo no es apropiado.

Si está utilizando un JDK> = 1.4, puede hacer algo como:

try { // Code that might throw an exception } catch (IOException e) { throw new RuntimeException(e); } catch (ClassNotFoundException e) { throw new RuntimeException(e); }

y la vuelta a RuntimeException tendrá la causa original incluida en su interior. De esta manera, alguien en la parte superior del hilo atrapando la RuntimeException - tus hilos captan RuntimeException para que no solo mueran en silencio, ¿no? - al menos puede imprimir el rastro COMPLETO de la pila de la causa.

Pero como otros han dicho y dirán, las excepciones se verifican por algún motivo. Haga esto solo cuando esté seguro de que sus clientes no pueden recuperarse del problema que está volviendo a lanzar como una excepción no verificada.

NOTA: Mejor que solo RuntimeException sería usar una excepción no verificada más específica si hay una disponible. Por ejemplo, si la única razón por la que su método podría arrojar una ClassNotFoundException se debe a que falta un archivo de configuración, puede volver a lanzar una MissingResourceException , que es una excepción no comprobada pero que brinda más información sobre por qué la está lanzando. Otras buenas excepciones de IllegalStateException para usar si describen el problema que está volviendo a lanzar son IllegalStateException , TypeNotPresentException y UnsupportedOperationException .

También tenga en cuenta que SIEMPRE es una buena idea que sus subprocesos capturen RuntimeException y, como mínimo, lo registren. Al menos de esta manera entiendes por qué tus hilos se van.

Answer 4

Aquí hay una buena compilación de las mejores prácticas de manejo de excepciones.

Dos puntos desde allí:

• El código de llamada no puede hacer nada con respecto a la excepción -> Convertirla en una excepción sin marcar
• El código de llamada tomará alguna acción de recuperación útil basada en la información en la excepción -> Convertirlo en una excepción marcada

Y puede lanzar RuntimeException con o sin excepción interna, dependiendo de lo que la persona que llama pueda hacer con ella. Si no está volviendo a lanzar la excepción interna, debe registrarla en su método, si es importante.