Las 10 preguntas principales sobre excepciones en Java

El artículo describe las 10 preguntas más frecuentes sobre excepciones en Java.

1. Verificable y no verificable

En resumen, las excepciones marcadas deben capturarse explícitamente en el cuerpo del método o declararse en la sección de lanzamientos del método. Las excepciones no marcadas son causadas por problemas que no se pueden resolver, como división por 0, puntero nulo, etc. Las excepciones marcadas son especialmente importantes porque espera que otros desarrolladores que utilicen su API sepan cómo manejar las excepciones. Por ejemplo, IOException es una excepción comprobada de uso común, mientras que RuntimeException es una excepción no comprobada. Antes de seguir leyendo, consulte el Diagrama jerárquico de excepciones en Java .

2. La mejor manera de abordar las excepciones

Si la excepción se puede manejar correctamente, se debe detectar; de lo contrario, se debe reenviar.

3. ¿Por qué las variables definidas en try no se pueden usar en catch o finalmente?

En el siguiente código, la línea s declarada en un bloque try no se puede utilizar en un bloque catch. Este código no se compilará.

try {
	File file = new File("path");
	FileInputStream fis = new FileInputStream(file);
	String s = "inside";
} catch (FileNotFoundException e) {
	e.printStackTrace();
	System.out.println(s);
}

La razón es que no se sabe exactamente en qué parte del bloque try se pudo haber generado la excepción. Es posible que la excepción se haya lanzado antes de que se declarara el objeto. Y esto es cierto para este ejemplo.

4. ¿Por qué Double.parseDouble(null) e Integer.parseInt(null) arrojan excepciones diferentes?

Así es, plantean diferentes excepciones. Este es un problema de JDK. Simplemente fueron diseñados por diferentes personas y no deberías preocuparte demasiado por eso.

Integer.parseInt(null);
// вызывает java.lang.NumberFormatException: null

Double.parseDouble(null);
// вызывает java.lang.NullPointerException

5. Excepciones básicas del tiempo de ejecución en Java

Éstos son algunos de ellos:

IllegalArgumentException
ArrayIndexOutOfBoundsException

Se pueden usar en una declaración if cuando no se cumple la condición, como aquí:

if (obj == null) {
   throw new IllegalArgumentException("obj не может быть равно null");

6. ¿Es posible detectar varias excepciones en un bloque de captura?

La respuesta es sí. Siempre que las clases de estas excepciones puedan rastrearse en la jerarquía de herencia de clases hasta la misma superclase, sólo se podrá utilizar esa superclase.

7. ¿Puede un constructor generar excepciones?

La respuesta es sí. Un constructor es simplemente un tipo especial de método. Aquí hay un ejemplo de código.

8. Lanzar excepciones en el bloque final.

En principio, puedes hacer esto de forma bastante legal:

public static void main(String[] args) {
	File file1 = new File("path1");
	File file2 = new File("path2");
	try {

		FileInputStream fis = new FileInputStream(file1);
	} catch (FileNotFoundException e) {
		e.printStackTrace();
	} finally {
		try {
			FileInputStream fis = new FileInputStream(file2);
		} catch (FileNotFoundException e) {
			e.printStackTrace();
		}
	}
}

Pero para mantener la legibilidad del código, debe declarar el bloque anidado try-catchcomo un método nuevo e insertar una llamada a este método en el bloque finally.

public static void main(String[] args) {
	File file1 = new File("path1");
	File file2 = new File("path2");
	try {

		FileInputStream fis = new FileInputStream(file1);
	} catch (FileNotFoundException e) {
		e.printStackTrace();
	} finally {
		methodThrowException();
	}
}

9. ¿Es posible utilizar return en un bloque finalmente?

Sí tu puedes.

10. ¿Por qué los desarrolladores manejan las excepciones en silencio?

Por ejemplo, estos fragmentos de código aparecen a menudo. Si el manejo adecuado de excepciones es tan importante, ¿por qué los desarrolladores continúan escribiéndolo de esta manera?

try {
     ...
} catch(Exception e) {
     e.printStackTrace();
}

Es más fácil ignorarlo. Pero incluso si esto se hace a menudo, no significa que sea correcto. Enlaces:

1. Excepciones no comprobadas en Java
2. La raíz de un árbol de excepciones jerárquico en Java
3. Preguntas sobre excepciones en stackoverflow

Artículo original