rango - propagacion de excepciones en java

¿Qué significa cuando el método principal lanza una excepción?

Question

Estoy revisando un examen parcial que hice en preparación para mi examen final mañana por la mañana. Entendí mal esta pregunta, pero no se señaló una respuesta correcta, y olvidé preguntarle al profesor al respecto.

Considere el siguiente fragmento de código:

public static void main(String[] args) throws FileNotFoundException

¿Cuál de las siguientes afirmaciones sobre este código es correcta?

1. El método principal está diseñado para detectar y manejar todo tipo de excepciones.
2. El método principal está diseñado para capturar y manejar la FileNotFoundException .
3. El método principal simplemente debe terminar si se produce la FileNotFoundException .
4. El método principal simplemente debe terminar si ocurre alguna excepción.

Yo había elegido la segunda opción.

Answer 1

Amigo, un poco tarde, pero la respuesta es la número 3.

El número 1 es falso porque no está manejando la excepción FileNotFoundException

El número 2 es falso por la misma razón.

El número 3 es cierto. Si se lanza una excepción FileNotFoundException, el método principal terminará.

El número 4 es falso. No terminaría en caso de CUALQUIER excepción. Terminaría solo en el caso de una excepción sin marcar o la excepción FileNotFoundException. Si no hay otras excepciones marcadas declaradas en la cláusula de ''lanzamientos'', significa que se están manejando dentro del método.

Answer 2

Aunque ya se ha elegido una respuesta para esta pregunta, creo que la respuesta correcta para su prueba es la número 3:

3. El método principal simplemente debe terminar si se produce la excepción FileNotFoundException.

Porque dice que debería , no lo haría .
Quiero decir, el código en el método puede capturar cualquier excepción, tanto marcada como no verificada, y cualquiera de ellas, tragarla, recuperarla o volver a realizarla, o no podría capturarla en absoluto.

Pero si atrapa una FileNotFoundException sin (re) lanzarlo en última instancia, está rompiendo su propio contrato: cualquier persona que llama no verá la excepción como se indica en la firma del método, porque el método lo manejó (tal vez incluso el compilador podría quejarse de ello). caso, diciendo que la excepción nunca se lanza, pero no estoy seguro aquí).

Creo que su examen intermedio planteaba una pregunta sobre el diseño en lugar de una implementación específica.

Answer 3

El método principal no es capturar ninguna excepción, sino que maneja la FileNotFoundException lanzándola a la fuente que invocó el método principal.

El tiempo de ejecución del sistema inicia las clases JVM, una clase específica entre las clases JVM invoca el método principal.

El manejo de los throws del método principal está a la merced de las clases JVM en ese caso.

• Puede leerlo en la especificación de lenguaje Java proporcionada por Oracle.
• Además, puede ver el código fuente de algunas de las JVM disponibles en el mercado, pero seguir ese camino lo lleva a otros lenguajes de programación, OpenJdk .

Pensé en compartir mi pequeña y humilde corteza de investigación en ese tema, espero que ayude a los curiosos :)

Answer 4

Estoy de acuerdo con algunas otras respuestas en que la respuesta correcta a la pregunta es la opción 3. La opción 4 dice:

4. El método principal simplemente debe terminar si ocurre alguna excepción.

Tenga en cuenta el "cualquiera" en esta opción. Aquí hay un ejemplo de código en el que se produce una excepción, pero main() no termina:

public static void main(String[] args) throws FileNotFoundException {
try {
methodThatThrowsACheckedException();
} catch (SomeCheckedException e) {
// do something to handle this exception
}
}

En este código se produce una excepción, pero el método no termina, ya que se ha configurado para manejar esta excepción. Si la excepción fuera una excepción UncheckedException , el método terminaría, por supuesto. Sin embargo, el punto de la opción 4 es que cualquier contraejemplo lo invalida, ya que dice que se produce una excepción.

La Opción 3, sin embargo, limita esta terminación para que solo ocurra cuando se lanza la excepción en la firma del método:

3. El método principal simplemente debe terminar si se produce la FileNotFoundException .

La razón por la que la opción 3 tiene más sentido es porque el código como el siguiente no tiene sentido en la práctica:

public static void main(String[] args) throws FileNotFoundException {
try {
methodThatThrowsFileNotFoundException();
} catch (FileNotFoundException e) {
// do something to handle this exception
}
}

No tiene mucho sentido declarar que un método lanza una excepción, pero capta esa excepción en el método (a menos que, tal vez, lo vuelvas a lanzar después de hacer algo, en cuyo caso la opción 3 aún se mantiene, ya que el método termina eventualmente). ).

Answer 5

La respuesta es 2 y 3.

2.El método principal está diseñado para capturar y manejar la excepción FileNotFoundException. 3.El método principal simplemente debe terminar si se produce la excepción FileNotFoundException.

Pero si no puede manejar la excepción, a pesar de que está diseñado para manejarlo y los programas se terminan de manera anormal.

las palabras clave de throws se utilizan para hacer que JVM maneje las excepciones que no podemos manejar, compila exitosamente pero muestra la excepción durante el tiempo de ejecución (si lo maneja en el método principal, entonces compila y ejecuta exitosamente).

4.El método principal simplemente debe terminar si ocurre alguna excepción. No es correcto siempre porque las excepciones que ocurren pueden ser manejadas en el método principal.

1.El método principal está diseñado para capturar y manejar todo tipo de excepciones. Es incorrecto, ya que JVM no maneja excepciones sin marcar.

Answer 6

La respuesta es el número 4,

4.- El método principal simplemente debe terminar si ocurre alguna excepción.

La cláusula de los lanzamientos solo establece que el método lanza una excepción FileNotFoundException comprobada y que el método de llamada debe atraparla o volver a realizarla. Si se lanza una excepción no verificada (y no se captura) en el método principal, también terminará.

Compruebe esta prueba:

public class ExceptionThrownTest {
@Test
public void testingExceptions() {
try {
ExceptionThrownTest.main(new String[] {});
} catch (Throwable e) {
assertTrue(e instanceof RuntimeException);
}
}
public static void main(String[] args) throws FileNotFoundException {
dangerousMethod();
// Won''t be executed because RuntimeException thrown
unreachableMethod();
}
private static void dangerousMethod() {
throw new RuntimeException();
}
private static void unreachableMethod() {
System.out.println("Won''t execute");
}
}

Como puede ver, si lanzo una RuntimeException el método terminará incluso si la excepción lanzada no es una FileNotFoundException