¿Está comprobando las excepciones en el código o utilizando try-catch una práctica mejor en Java?

Question

Hice que alguien me mencionara que detectar todas las excepciones no es necesariamente una buena práctica (por ejemplo, NullPointerException). Estoy buscando una explicación de cuando esto es algo bueno, cuando no lo es, y por qué es como tal: D

Gracias!

badPanda

Answer 1

Para ampliar las excepciones verificadas de Bozho, normalmente se manejan las excepciones que espera que ocurran, independientemente de cuán perfecto sea su código (es decir: un cable de red está desenchufado y usted detecta y una excepción de IO). Usted declara que los métodos arrojan excepciones controladas, ya que otro código debe ocuparse de cómo manejar estas excepciones.

Las excepciones no comprobadas suelen utilizarse para situaciones inesperadas, por ejemplo, NullPointerExceptions a menudo aparecen porque el programa debe haber arrojado una excepción comprobada, datos filtrados, valores predeterminados, etc. No están marcadas y suelen ser inesperadas, por lo que no es necesario atrápalos.

Esto no es cierto el 100% del tiempo, pero como un enfoque general así es como funciona, especialmente en Java.

Answer 2

En resumen:

Las excepciones comprobadas son para la captura de

excepciones no comprobadas y los errores se puede dejar a burbujear. (estas son las subclases de RuntimeException y Error).

Esto se debe a que las "excepciones comprobadas" son "esperadas" y el programa puede recuperarse de ellas. Las excepciones desaprobadas son tales que el programa no puede recuperar (fácilmente).

Sun's tutorial dice (se trata de decidir qué tipo de excepción se debe crear, pero también es informativo en el otro lado - es decir, cuando el uso de excepciones):

Aquí está la guía resultado final: Si un cliente puede razonablemente se espera que se recupere de una excepción, conviértalo en una excepción comprobada. Si un cliente no puede hacer nada para recuperarse de la excepción, conviértalo en una excepción no verificada.

Answer 3

Y agregando a la respuesta de bozho, a veces también depende del tipo de aplicación, ya que en algunos casos puede que tenga que manejarla para realizar algún trabajo al respecto y, en algunos casos, puede dejarla para manejar por la persona que llama o en última instancia para terminar.

Answer 4

Las excepciones que no son causadas por errores de programación y/o pueden recuperarse deben capturarse. Otros no deberían ser En Java se supone que las excepciones generalmente comprobadas se detectan mientras RunTimeExceptions y Errors no.

Una excepción de puntero nulo es causada por un error de programación, es decir, falta de comprobación nula, por lo que no debe capturarse. Sin embargo, también puede haber situaciones en las que desee capturar una RunTimeException únicamente con el fin de iniciar sesión antes de devolverla.

Answer 5

El título de su pregunta parece preguntar si es mejor verificar y manejar las condiciones de error en el código o si es mejor ponerlo todo en un bloque de prueba y lidiar con las excepciones en una captura.

Si es simple, definitivamente verifique si hay un error y trátelo en lugar de usar un try-catch.Por ejemplo, si puede tratar una entrada no válida marcándola e imprimiendo un tipo de mensaje "por favor intente de nuevo", no usaría un try-catch.

Me gusta pensar de esta manera: si puedo evitar cuidadosamente el error introducido por la excepción, verifique las condiciones que lo causarían y tratar con ellos. Si no puede verificar fácilmente las condiciones o lidiar fácilmente con ellas, use un try-catch para manejarlo.

Answer 6

Las excepciones RuntimeExceptions pueden considerarse (la mayoría de los casos) como "errores de programación". Por ejemplo, piense en mostrar un objeto de una pila antes de verificar si realmente contiene algún elemento. En una implementación adecuada, debería haber algún método isVampty() para verificar el estado de la pila. Si el programador es perezoso u olvida revisar la pila, se debe lanzar una excepción para indicar un error de programación.

Este tipo de excepciones NO se deben tomar. La idea es bloquear el programa e informar al programador de su error.

Las excepciones controladas, por otro lado, como han indicado otros, son excepciones de las que se espera que los programas se recuperen. Aunque esto suena como una buena idea en la práctica, a menudo se lanzan excepciones marcadas cuando en realidad no se puede hacer nada para resolver la causa de la excepción. Así que terminas con muchos códigos repetitivos (es decir, try-catch-blocks, cuyos bloques de excepción no hacen más que registrar o imprimir la causa de la excepción). Afaik, ningún lenguaje de programación más reciente admite excepciones comprobadas debido a esto (incluso a JavaFX).

Answer 7

Siempre implemento un try...catch(Throwable) (un Throwable es realmente un error y su aplicación no debe realizar ninguna otra operación después de obtener uno de esos) en UN punto en mi código, cuando es extremadamente importante saber qué pasó para que puede ser registrado Ese lugar es generalmente el método main.

También tengo try ... catch (Exception) en una clase ejecutable , o una clase que procesa, por ejemplo, un registro que se puede procesar independientemente de los demás. En ese caso, la aplicación debería continuar incluso si parte de su procesamiento falla, no importa si sé qué excepción se lanzará o no, capto la excepción, la registro, aborto esa entrada de procesamiento, y sigo adelante.

La regla de oro es que debe detectar una excepción si va a hacer algo al respecto (ya sea abortar el procesamiento de algo, ejecutar una rutina alternativa o seguir adelante, siempre que sepa lo que está haciendo), si no vas a hacer algo al respecto, no lo atrapes.

Y no use su creador IDE try...catch para ocultar su excepción, en su lugar permita que agregue las excepciones a la firma del método.