Estoy escribiendo código para leer archivos en Java.

Tengo un método principal que arroja tres Excepciones. Me pregunto cuál sería el impacto si cambiara el orden de escritura de las excepciones en la misma línea de public static void main(String[] args).

public class SwitchTester {

    private static Scanner pathInput;

    public static void main(String[] args) throws IOException, NoSuchElementException, IllegalStateException{

Utilizo el código dentro del método principal. El orden de las excepciones que utilizo es IOException, NoSuchElementException, IllegalStateException en este código. ¿Importaría mantener el mismo orden en la línea principal? ¿Importaría mantener los lanzamientos en la línea principal o nada?

    try{         
        pathInput = new Scanner(path);
    }catch(IOException ioException){
        System.err.println("Error opening file. Terminating.");
        System.exit(1);
    }

    System.out.printf("%-10s%-15s%-15s%10s%n", "Port", "Destination",
             "Source", "Data-type");

    //readRecords
    try{
        while(pathInput.hasNext()){ //while there is more to read, display record contents
            System.out.printf("%-10s%-15s%-15s%10s%n", pathInput.next(), 
                    pathInput.next(), pathInput.next(), pathInput.next());
        }
     }catch(NoSuchElementException elementException){
         System.err.println("File improperly formed. Terminating.");
     }catch(IllegalStateException stateException){
         System.err.println("Error reading from file. Terminating.");
     }

¡Agradecería tu respuesta! ¡Gracias!

2
In-young Choung 28 ene. 2016 a las 23:37

3 respuestas

La mejor respuesta

El orden de las excepciones en su cláusula throws no tiene un impacto funcional en el código de llamada. Tampoco se omiten los arrojables sin marcar (los que se derivan de Error o RuntimeException). Sin embargo, debe declarar las excepciones marcadas; no son opcionales.

JLS 8.4.6 documenta los requisitos para la cláusula de lanzamientos:

Está permitido, pero no es obligatorio, mencionar las clases de excepción sin marcar ( §11.1.1) en una cláusula throws.

En general, con lo que debe tener cuidado es si desea declarar una superclase en la cláusula throws o subclases discretas. Por ejemplo, generalmente es una mala práctica decir throws Exception en lugar de p. Ej. throws FileNotFoundException porque impone una mayor carga a las personas que llaman que quieren manejar las excepciones lanzadas de manera inteligente.

1
Mark Peters 28 ene. 2016 a las 20:48

Cuando detecte las excepciones, siempre debe capturar la mayoría de specific primero y luego la mayoría de generic, pero si está lanzando el tipo de excepciones, no es necesario que las detecte.

Para obtener más información sobre la excepción, consulte jerarquía de excepción y este paquete-árbol

1
Abdelhak 28 ene. 2016 a las 20:49

El orden en el que se enumeran las excepciones en la cláusula throws de la declaración del método no importa por completo. Definitivamente no tiene que tener ninguna relación con dónde arroja las excepciones en el código.

Suponiendo que este es un método principal llamado solo desde la JVM, y ninguno de su código realmente llama a este método, este es un momento en el que estaría perfectamente bien ahorrarse algo de tipeo y escribir throws Exception. (Por otro lado, si refactoriza el método principal para que llame a métodos separados que manejen diferentes funciones, entonces querrá que esos métodos sean más descriptivos de las excepciones marcadas que arrojan).

2
Nathan Hughes 28 ene. 2016 a las 21:07