Método de declaración para generar una excepción y una subclase de esta excepción

Question

¿Es significativo declarar un método para lanzar una excepción y una subclase de esta excepción, , p. IOException y FileNotFoundException?

Supongo que se usa para manejar ambas excepciones por un método de llamada diferente. Sin embargo, ¿es posible manejar ambas excepciones si el método arroja solo el más genérico es decir IOException?

Answer 1

Sin embargo, ¿es posible manejar ambas excepciones si el método arroja solo la más genérica, es decir, IOException?

Absolutamente. Todavía puede captura por separado:

try { 
    methodThrowingIOException(); 
} catch (FileNotFoundException e) { 
    doSomething(); 
} catch (IOException e) { 
    doSomethingElse(); 
} 

Por lo tanto, no hace ninguna diferencia a lo que la persona que llama puede hacer si el método declara tanto - es redundante. Sin embargo, puede enfatizar las excepciones que podría considerar. Esto podría hacerse mejor en Javadoc que solo la declaración de lanzamientos.

Answer 2

Sin embargo, ¿es posible manejar ambas excepciones si el método arroja solo las más genéricas, es decir,> IOException?

catch(IOException ex){ 
if(ex instanceof FileNotFoundException){} 
} 

Pero esto no se ve limpia, Lanzar tanto excepción se ve bien, incluso persona que llama llegar a conocer a que este método puede lanzar estas estas excepciones, por lo que lo manejará adecuadamente

Answer 3

Sí, es posible manejar ambos si el método solo arroja IOException.

La mejor manera de responder a esta pregunta es escribir una prueba para demostrarlo y probarlo. Deje que la JVM le diga la respuesta. Será más rápido que preguntar aquí.

Answer 4

sí. cuando ciertas excepciones especializadas se pueden manejar correctamente. Es, si se maneja con las excepciones de la siguiente manera:

try { 
} catch (FileNotFoundException f) { 
//Try a different file 
} catch (IOException ioe) { 
//Fatal, Maybe bad blocks ... Bail out... 
} catch (Exception e) { 
//Something went wrong, see what it is... 
} 

Answer 5

¿Tiene algún sentido para declarar un método para producir una excepción y una subclase de esta excepción, por ejemplo, IOException y FileNotFoundException?

Usualmente IDEs más desconocidos Sé incluso de emitir advertencias para tales declaraciones. Lo que puede y debe hacer es documentar las diferentes excepciones arrojadas en Javadoc.

Sin embargo, ¿es posible manejar ambas excepciones si el método arroja solo las más genéricas, es decir, IOException?

Sí, es necesario asegurarse de que los bloques de captura estén en el orden correcto, es decir, más específicos primero.bloques catch se evalúan en el orden en que se definen, por lo que aquí

try { 
    ... 
} catch (FileNotFoundException e) { 
    ... 
} catch (IOException e) { 
    ... 
} 

si la excepción lanzada es un FileNotFoundException, que será capturado por el primer catch bloque, de lo contrario se caerá a la segunda y tratados como una general IOException. El orden opuesto no funcionaría ya que catch (IOException e) capturaría todos IOException s incluyendo FileNotFoundException. (. De hecho, este último como resultado una IIRC error de compilación)

Answer 6

declarar, que el método puede lanzar (más genérica) IOException, y (más específica) FileNotFoundException es generalmente una buena cosa - es una información adicional para las personas que usen su código más adelante. Tenga en cuenta que debe indicar explícitamente en JavaDoc, bajo qué circunstancias se arroja cada una de las excepciones.

Ellos todavía será capaz de distinguir las excepciones y manejarlas de forma diferente utilizando construcciones de captura como ésta:

try { 
    yourAwesomeMethod() 
} catch (FileNotFoundException ex) { 
    // handle file-not-found error 
} catch (IOException ex) { 
    // handle other IO errors 
}