Excepciones y archivos en Java

Una excepción es un objeto que describe un problema que interrumpe un programa en ejecución. Lanzarla detiene la sentencia actual. Java omite el trabajo normal restante hasta encontrar un manejador de excepciones que coincida; si no lo hay, la excepción se propaga hacia atrás por los métodos que llamaron.

Reconoce el tipo de problema

La falta de un punto y coma es un error en tiempo de compilación: el programa no puede compilarse. Una excepción ocurre cuando el código compilado se ejecuta con datos que provocan un problema.

Los índices de los arreglos empiezan en 0, por lo que una longitud de 3 significa que los índices válidos son 0, 1 y 2. La división en coma flotante sigue reglas diferentes: 10.0 / 0 produce Infinity; no lanza la excepción de la división entera.

Lee una traza desde arriba

Aquí tienes una clase completa, sin líneas en blanco antes de la primera línea:

public class Average {
    static int average(int[] values) {
        int sum = 0;
        for (int value : values) sum += value;
        return sum / values.length;
    }
    public static void main(String[] args) {
        int[] values = new int[0];
        System.out.println(average(values));
    }
}

El arreglo está vacío, por lo que su longitud es 0. La división de la línea 5 falla. La traza es:

Exception in thread "main" java.lang.ArithmeticException: / by zero
    at Average.average(Average.java:5)
    at Average.main(Average.java:9)

1. Lee la primera línea para conocer la clase de excepción y el mensaje.
2. Lee el primer marco at para localizar dónde se detectó el problema.
3. Lee hacia abajo para identificar a quienes llamaron: main llamó a average en la línea 9.
4. Si los primeros marcos pertenecen a la biblioteca de Java, busca el primero que nombre una clase tuya. Si falla Integer.parseInt, pueden aparecer marcos de la biblioteca antes de la llamada en tu código.

La traza sigue la pila de llamadas, la cadena de llamadas a métodos activas. Te indica dónde investigar, pero el valor incorrecto puede haberse creado antes. Aquí la división detecta el problema; quien llamó proporcionó el arreglo vacío. Decide si debe rechazarse o manejarse una entrada vacía antes de calcular una media.

Inspecciona el objeto de excepción

e.getMessage() devuelve el mensaje y puede devolver null. e.toString() incluye el nombre de la clase y, cuando existe, el mensaje. e.printStackTrace() imprime la traza en el error estándar. Una sección Caused by: muestra una excepción anterior conservada dentro de una excepción envoltorio.

Los mensajes de NullPointerException generados por la JVM suelen identificar la expresión nula. En cambio, una excepción creada explícitamente puede tener un mensaje personalizado o ninguno. Sigue la referencia hasta donde debería haber recibido un objeto.

Una excepción sin manejar que sale de main termina el hilo principal; eso termina un programa de un solo hilo. Corrige en el código los fallos, como los índices incorrectos. Planifica la recuperación ante problemas externos esperados, como un archivo inexistente o una entrada de usuario no válida.

Las clases de excepciones usan las reglas de herencia que ya conoces. Un objeto de una subclase que se lanza también pertenece a su superclase, lo que explica tanto las categorías de excepciones de Java como la forma en que un manejador las reconoce.

Sigue la jerarquía

Solo pueden lanzarse objetos de Throwable o de sus subclases. Por debajo hay dos ramas principales:

Throwable
  Error
    OutOfMemoryError
    StackOverflowError
  Exception
    RuntimeException
      IllegalArgumentException
        NumberFormatException
      NullPointerException
      IndexOutOfBoundsException
        ArrayIndexOutOfBoundsException
    IOException
      FileNotFoundException
      NoSuchFileException

Error describe fallos graves del entorno de ejecución. Una aplicación normal no debería intentar recuperarse de una memoria dinámica agotada o de una pila agotada por una recursión interminable. Exception describe problemas que una aplicación puede manejar, incluida su rama RuntimeException.

Ambos tipos se lanzan en tiempo de ejecución. La palabra «comprobada» describe la comprobación del manejo por el compilador, no un momento anterior en el que ocurre el fallo. No comprobada tampoco significa inofensiva: una referencia nula sin manejar puede detener un programa.

Aplica la regla de capturar o declarar

La lectura de un archivo puede fallar incluso con código correcto. Un método auxiliar puede dejar la decisión a quien lo llama:

import java.io.IOException;
import java.nio.file.Files;
import java.nio.file.Path;
import java.util.List;

class Names {
    static List<String> load(Path file) throws IOException {
        return Files.readAllLines(file);
    }
}

Files.readAllLines puede lanzar la excepción comprobada IOException. La declaración pasa esa posibilidad a quien llama, que también debe capturarla o declararla. Si se elimina throws IOException sin añadir un manejador, el método auxiliar no compila. Un método que usa Integer.parseInt no tiene una obligación equivalente del compilador porque NumberFormatException es no comprobada.

Los fallos comprobados suelen describir condiciones que quien llama puede prever, como la desaparición de un archivo. Los fallos en tiempo de ejecución suelen identificar errores o argumentos no válidos. Son razones de diseño útiles, pero la cadena de superclases determina la categoría. Una clase personalizada que extiende RuntimeException sigue siendo no comprobada aunque quien llama pueda recuperarse.

Relaciona los manejadores mediante la herencia

catch (IOException e) puede manejar una FileNotFoundException o una NoSuchFileException. catch (Exception e) también captura excepciones en tiempo de ejecución; puede convertir un fallo de código en un mensaje de entrada engañoso. catch (Throwable e) también alcanza la rama Error y rara vez es apropiado para la recuperación normal.

Para clasificar una clase desconocida, sigue su herencia hacia arriba en la documentación de la API. InputMismatchException extiende NoSuchElementException, que extiende RuntimeException, por lo que es no comprobada. InterruptedException extiende Exception fuera de la rama de ejecución, por lo que es comprobada. Se permite declarar un tipo no comprobado en una cláusula throws, pero eso no cambia su categoría.

Un bloque try marca el trabajo que puede fallar. Un bloque catch que coincida proporciona al programa una acción útil a continuación, como pedir otro valor. Manejar la excepción no reintenta por sí solo la sentencia que falló.

Sigue las ramas

System.out.println("A");
try {
    System.out.println("B");
    int value = Integer.parseInt("4x");
    System.out.println("C");
} catch (NumberFormatException e) {
    System.out.println("D: " + e.getMessage());
}
System.out.println("E");

La salida es A, B, D: For input string: "4x" y E, cada uno en su propia línea. La conversión falla, por lo que Java omite C y entra en el manejador correspondiente. Cuando ese manejador termina normalmente, la ejecución continúa después de toda la sentencia. Si la conversión tiene éxito, se omite el manejador. Si el bloque lanza una ArithmeticException, este manejador no coincide y la excepción se propaga.

Reintenta con una entrada nueva

Lee una línea completa antes de convertirla. El siguiente bucle acepta un número entero y maneja el final de la entrada del teclado informando de que no se proporcionó ningún valor:

import java.util.Scanner;

class WholeNumbers {
    static int readWholeNumber(Scanner in) {
        while (in.hasNextLine()) {
            String line = in.nextLine();
            try {
                return Integer.parseInt(line.trim());
            } catch (NumberFormatException e) {
                System.out.println("Please enter a whole number.");
            }
        }
        throw new IllegalStateException("No number supplied");
    }
}

Para las entradas «twenty» y «20», el manejador imprime una vez, el bucle lee una línea nueva y el método devuelve 20. trim() elimina los caracteres de espacio en blanco que rodean el texto: de otro modo, Integer.parseInt(" 20") falla. La conversión acepta un signo opcional y dígitos que representen un entero dentro del rango permitido.

Un scanner basado en unidades de entrada necesita otra solución. Cuando nextInt() encuentra «ten», su InputMismatchException deja esa unidad sin leer. Capturarla y volver a llamar a nextInt() repite el fallo indefinidamente. Consume la unidad incorrecta con next() o descarta la línea con nextLine() antes de reintentar. hasNextInt() puede comprobar una unidad antes de la conversión.

Mantén utilizable el estado recuperado

Una variable declarada dentro de try solo existe en ese bloque. Si el código posterior necesita el resultado, declárala fuera y haz que cada ruta que continúe le asigne un valor válido:

int quantity;
try {
    quantity = Integer.parseInt("bad");
} catch (NumberFormatException e) {
    quantity = 0;
}
System.out.println(quantity);

Cero solo es apropiado aquí si el programa lo define como un valor alternativo válido. Dejar quantity sin asignar en el manejador provoca un error de asignación definida en tiempo de compilación.

Captura el tipo específico que puedes manejar. Un manejador vacío pierde el problema sin avisar; un catch (Exception e) general puede etiquetar un fallo de referencia nula como un número incorrecto. La recuperación debe volver a preguntar, omitir un elemento, elegir un valor predeterminado válido, informar del fallo o propagar una excepción significativa. Para límites sencillos y previsibles, comprueba primero: index >= 0 && index < list.size() evita índices de lista tanto negativos como demasiado grandes.

Un archivo puede no existir, no poder leerse o estar lleno de registros mal formados. Esos fallos necesitan respuestas diferentes. Varios manejadores permiten que un try los distinga, mientras que la posición del bloque determina cuánto trabajo se detiene cuando algo falla.

Coloca primero los manejadores específicos

Java comprueba los manejadores de arriba abajo y ejecuta el primero que coincide. No sigue ejecutando manejadores posteriores para la misma excepción.

import java.io.IOException;
import java.nio.file.Files;
import java.nio.file.NoSuchFileException;
import java.nio.file.Path;

class FirstCount {
    static void show(Path file) {
        try {
            int count = Integer.parseInt(Files.readString(file).trim());
            System.out.println(count);
        } catch (NoSuchFileException e) {
            System.out.println("File not found: " + file.toAbsolutePath());
        } catch (IOException e) {
            System.out.println("Could not read: " + file.toAbsolutePath());
        } catch (NumberFormatException e) {
            System.out.println("The file must contain one whole number.");
        }
    }
}

NoSuchFileException extiende IOException, por lo que debe ir primero. Invertirlas hace que el manejador específico sea inalcanzable e impide la compilación. La excepción de conversión no está relacionada con IOException, por lo que esos dos manejadores pueden aparecer en cualquier orden.

Un manejador de una excepción comprobada también debe ser pertinente para el trabajo protegido. Se rechaza capturar IOException alrededor de solo int count = 5; porque ese bloque no puede lanzarla. Esta restricción no se aplica de la misma forma a los tipos no comprobados ni a los tipos generales Exception y Throwable.

Comparte un manejador cuando la respuesta sea la misma

Una captura múltiple une tipos de excepciones no relacionados con |:

try {
    String[] parts = "Ana".split(",");
    int age = Integer.parseInt(parts[1]);
    System.out.println(age);
} catch (NumberFormatException | ArrayIndexOutOfBoundsException e) {
    System.out.println("Invalid record: " + e.getMessage());
}

Aquí la ausencia del segundo campo provoca la excepción de índice. Un campo presente pero no numérico provocaría la excepción de conversión, y ambos reciben la misma respuesta. El parámetro de la captura múltiple es implícitamente final. Las alternativas no pueden ser una subclase y su superclase: FileNotFoundException | IOException no es válido porque IOException ya cubre ambas.

Decide qué debe omitir un fallo

Considera los textos «3», «x» y «5». Con un try alrededor de todo el bucle, el procesamiento se detiene en «x» y la suma hasta ese momento es 3. Coloca el try dentro del bucle para recuperarte por separado de cada elemento:

int sum = 0;
for (String text : new String[] {"3", "x", "5"}) {
    try {
        sum += Integer.parseInt(text);
    } catch (NumberFormatException e) {
        System.out.println("Skipped: " + text);
    }
}
System.out.println(sum);

Esto imprime Skipped: x y después 8. El bucle continúa porque su cuerpo manejó el fallo de ese registro. Los manejadores anidados buscan hacia fuera desde el bloque protegido más interno; un manejador interno que no coincide da una oportunidad a uno externo. Elige la unidad de trabajo más pequeña que deba fallar en conjunto: un registro para datos incorrectos, la operación de archivo para un fallo de lectura.

Parte del trabajo debe realizarse tanto si una operación tiene éxito como si falla. Un bloque finally se ejecuta cuando el control sale de su sentencia try, incluso cuando se propaga una excepción o un método retorna.

Sigue una excepción que no coincide

try {
    System.out.println("1");
    int[] values = new int[2];
    values[2] = 7;
    System.out.println("2");
} catch (NumberFormatException e) {
    System.out.println("3");
} finally {
    System.out.println("4");
}
System.out.println("5");

Solo se imprimen 1 y 4 antes de que se propague la ArrayIndexOutOfBoundsException. El índice 2 está fuera del arreglo de dos elementos. El manejador no coincide, pero finally se ejecuta igualmente. La sentencia que imprime 5 está fuera del bloque de limpieza, por lo que la excepción que se propaga la omite.

Si el trabajo protegido lanza en cambio una NumberFormatException que coincide después de imprimir 1, el manejador imprime 3, la limpieza imprime 4 y la ejecución continúa hasta 5. En una ruta satisfactoria no se ejecuta ningún manejador, pero la limpieza sí.

Los valores de retorno se preparan antes de la limpieza

class Cleanup {
    static int result() {
        try {
            return 1;
        } finally {
            System.out.println("cleanup");
        }
    }
}

La expresión de retorno se evalúa primero. Después Java imprime cleanup y quien llamó recibe 1. Un break o continue que sale de una región protegida también ejecuta su limpieza antes de que surta efecto la transferencia de control.

Mantén return fuera de finally. Un return 2; allí sustituiría el valor de retorno pendiente y podría incluso descartar una excepción pendiente. Una excepción lanzada por la limpieza también puede sustituir el fallo original. La limpieza no debería introducir un segundo resultado que entre en conflicto. La opción -Xlint:finally del compilador advierte cuando un bloque finally no puede terminar normalmente.

Cierra un objeto solo si se abrió

El patrón manual más antiguo necesita una variable visible para el bloque de limpieza:

import java.io.IOException;
import java.nio.charset.StandardCharsets;
import java.nio.file.Path;
import java.util.Scanner;

class ManualRead {
    static void firstLine(Path file) throws IOException {
        Scanner sc = null;
        try {
            sc = new Scanner(file, StandardCharsets.UTF_8);
            if (sc.hasNextLine()) System.out.println(sc.nextLine());
            if (sc.ioException() != null) throw sc.ioException();
        } finally {
            if (sc != null) sc.close();
        }
    }
}

Si la apertura falla, sc sigue siendo null, por lo que la comprobación evita que la limpieza lance una nueva excepción de referencia nula. Para los objetos que se pueden cerrar, try-with-resources elimina esta gestión y maneja los fallos simultáneos de forma más segura.

finally no garantiza que la máquina siga funcionando. System.exit termina la JVM sin ejecutar esta limpieza; un fallo o un corte de energía también la impiden. Un bucle infinito que nunca sale del bloque tampoco llega nunca a su finally.

Tus métodos pueden rechazar solicitudes no válidas antes de cambiar un objeto. Elige una excepción que identifique el problema y permita responder a quien llama.

Lanza un objeto en el momento

class Percentage {
    private int value;

    public void setPercentage(int value) {
        if (value < 0 || value > 100) {
            throw new IllegalArgumentException(
                "percentage must be 0 to 100, was " + value);
        }
        this.value = value;
    }
}

Llamar a setPercentage(120) lanza una excepción con el mensaje percentage must be 0 to 100, was 120. La asignación no se ha ejecutado, por lo que el campo conserva su valor anterior. Esto es fallo inmediato: informa de la solicitud no válida en el punto donde puedes explicarla. La misma comprobación en un constructor impide que se devuelva un objeto no válido.

throw necesita un objeto de excepción, como en throw new IllegalArgumentException("bad quantity");. Un nombre de clase por sí solo no es un objeto. Una sentencia normal situada directamente después de un throw incondicional en el mismo bloque es inalcanzable.

Objects.requireNonNull(name, "name must not be null"), de java.util.Objects, es una forma cómoda de comprobar si hay un valor nulo. Que un pedido ya enviado rechace otro artículo es un problema de estado; una cantidad negativa de artículos es un problema de argumento.

Declara qué puede salir del método

Un método auxiliar de lectura de archivos puede declarar su fallo comprobado:

import java.io.IOException;
import java.nio.file.Files;
import java.nio.file.Path;
import java.util.List;

class NameLoader {
    static List<String> loadNames(Path file) throws IOException {
        return Files.readAllLines(file);
    }
}

throw es una sentencia ejecutable. throws pertenece a la declaración del método e indica a quienes llaman qué fallos comprobados deben manejar. No captura un fallo ni hace que el método continúe después de él. Cada método que llama debe capturar IOException o declararla a su vez. Una cláusula catch también puede volver a lanzar el mismo objeto con throw e;.

Captura la excepción donde sea posible dar una respuesta útil. Un método auxiliar normalmente no puede pedir al usuario que seleccione otro archivo, pero main sí. Imprimir «error» y devolver una lista vacía haría que se confundiera un archivo inexistente con uno realmente vacío. Un pequeño experimento puede permitir que main declare throws IOException; un programa terminado maneja los fallos esperados con mensajes útiles. Los tipos no comprobados pueden declararse como documentación aunque el compilador no lo exija.

Respeta el contrato heredado

Si una interfaz declara read() throws IOException, un método que lo sobrescribe puede declarar IOException, una subclase comprobada más específica o ninguna excepción comprobada. No puede ampliar la declaración a Exception. Puede declarar tipos no comprobados. Un método que sobrescribe Object.toString() no puede añadir IOException, ya que el método heredado no declara excepciones comprobadas. Las llamadas mediante el tipo de interfaz siguen teniendo que manejar su IOException declarada, aunque una implementación no declare ninguna.

Una excepción estándar suele ser suficiente. Crea una clase personalizada cuando quienes llaman necesiten reconocer un problema específico del programa, como existencias insuficientes o un registro de datos mal formado, y responder de forma diferente.

Elige la superclase de forma deliberada

Extender Exception crea una excepción comprobada. Extender RuntimeException crea una excepción no comprobada. Usa el diseño comprobado cuando quienes llaman deban prever un fallo recuperable del dominio; usa el diseño no comprobado para un uso incorrecto o un fallo de programación.

class OutOfStockException extends Exception {
    public OutOfStockException(String message) {
        super(message);
    }
}

super(message) almacena el mensaje en el mecanismo heredado de excepciones, por lo que getMessage() lo devuelve. Por convención, el nombre de la clase termina en Exception. Los campos adicionales y los métodos de acceso pueden ofrecer detalles estructurados, como las cantidades solicitada y disponible.

Mantén las existencias sin cambios tras un fallo

import java.util.HashMap;

class Inventory {
    private final HashMap<String, Integer> stock = new HashMap<>();

    Inventory() {
        stock.put("pens", 12);
    }

    void remove(String item, int quantity) throws OutOfStockException {
        if (quantity <= 0) {
            throw new IllegalArgumentException("quantity must be positive");
        }
        int available = stock.getOrDefault(item, 0);
        if (quantity > available) {
            throw new OutOfStockException("Requested " + quantity
                + " of " + item + ", only " + available + " in stock");
        }
        stock.put(item, available - quantity);
    }
}

Partiendo de 12 bolígrafos, retirar 5 deja 7. Una solicitud posterior de 10 lanza una excepción y quedan 7 porque la actualización se realiza después de todas las comprobaciones. Quien llama debe manejar o declarar el fallo comprobado de existencias; el fallo por cantidad no válida es no comprobado. Un programa que necesite una respuesta distinta para un artículo desconocido podría usar una UnknownItemException relacionada, con ambos tipos del dominio bajo una clase base InventoryException.

Envuelve sin perder el problema original

Un analizador puede transformar un fallo de conversión de bajo nivel en un fallo de un registro:

class InvalidRecordException extends Exception {
    public InvalidRecordException(String message) {
        super(message);
    }
    public InvalidRecordException(String message, Throwable cause) {
        super(message, cause);
    }
}

Dentro del método de análisis, un manejador puede hacer lo siguiente:

catch (NumberFormatException e) {
    throw new InvalidRecordException(
        "Line 3: quantity is not a number: x", e);
}

La excepción envoltorio proporciona a quien llama una categoría significativa y un número de línea. Su getCause() devuelve la NumberFormatException original y una traza impresa conserva una sección Caused by:. Construir una nueva excepción solo con el mensaje anterior pierde el objeto original y su traza.

java.io.UncheckedIOException es una clase envoltorio no comprobada ya disponible, específica para IOException. Sus constructores aceptan la causa, con un mensaje opcional. Puede transmitir un fallo de archivo a través de un método que sobrescribe otro y no puede añadir una declaración comprobada. Envolver cambia el tipo que ve quien llama; no repara el problema del archivo. Mantén las decisiones normales de los bucles como condiciones y break, sin inventar excepciones para el flujo habitual.

Un archivo almacena bytes, mientras que tu programa trabaja con caracteres y números. Para leer correctamente se necesitan la ubicación y la codificación de caracteres adecuadas, además de una convención clara para las líneas y el texto numérico.

Encuentra la ubicación real

Una ruta relativa comienza en el directorio de trabajo del programa. No comienza en la carpeta que contiene el código fuente. Una ruta absoluta comienza en la raíz del sistema de archivos, como /home/ana/data/scores.txt, o en la raíz de una unidad en Windows.

Path file = Path.of("data", "scores.txt");
System.out.println(System.getProperty("user.dir"));
System.out.println(file.toAbsolutePath());
System.out.println(file.getFileName());

Importa java.nio.file.Path. Crear este Path no abre nada ni comprueba si existe. toAbsolutePath() revela dónde buscará Java y getFileName() da scores.txt. Un IDE suele usar la carpeta del proyecto como directorio de trabajo. Las barras diagonales en "data/scores.txt" funcionan en Windows, Linux y macOS. Un literal de ruta de Windows que use barras invertidas necesita secuencias de escape, como en "C:\\data\\scores.txt". La clase más antigua java.io.File también representa una ubicación; convierte con toPath() o toFile().

Relaciona los bytes con los caracteres

UTF-8 codifica todos los caracteres Unicode. Los caracteres latinos básicos ocupan un byte; los demás ocupan de dos a cuatro. El texto «café» contiene cuatro caracteres pero cinco bytes en UTF-8 porque «é» ocupa dos. Leer esos bytes como ISO-8859-1 puede producir «café». Usa la codificación que se utilizó al escribir.

Los métodos de texto de Files usan UTF-8 de forma predeterminada. Las clases como FileWriter y un scanner abierto sin una codificación usan la codificación predeterminada, que pasó a ser UTF-8 en Java 18; las instalaciones anteriores pueden diferir. StandardCharsets.UTF_8, de java.nio.charset, hace explícita la elección. Los bytes no válidos leídos por Files.readAllLines producen MalformedInputException, una subclase de IOException.

Lee líneas sin restos de los fines de línea

Con un terminador después de cada línea, «a» y «b» necesitan cuatro bytes con fines de línea LF y seis con fines de línea CRLF. BufferedReader.readLine(), Files.readAllLines y Scanner.nextLine() eliminan los fines de línea reconocidos. Dividir una cadena completa con split("\n") deja el \r de Windows, por lo que convertir "12\r" con parseInt falla. Prefiere los métodos de lectura de líneas o elimina los espacios del texto. System.lineSeparator() y el formato %n producen el fin de línea del sistema actual.

Mantén la coherencia de los archivos numéricos

Integer.parseInt acepta texto entero, sin separador decimal. Double.parseDouble("3.5") acepta un punto; Double.parseDouble("3,5") falla. Estos métodos de análisis ignoran la configuración regional. Los métodos numéricos de Scanner y el formato decimal normal siguen la configuración regional, por lo que una configuración alemana u holandesa puede esperar «3,5» y producir «3,50». Usa scanner.useLocale(Locale.ROOT) y String.format(Locale.ROOT, "%.2f", value) para datos con punto decimal; importa java.util.Locale.

Las ubicaciones inexistentes suelen producir NoSuchFileException con Files o Scanner(Path), mientras que los constructores más antiguos que reciben nombres de archivo pueden producir FileNotFoundException. Los fallos de permisos pueden producir AccessDeniedException. Estos son fallos de entrada y salida comprobados: una expresión de ruta correcta por sí sola no puede impedirlos.

Un archivo abierto usa un recurso del sistema operativo. Cerrarlo lo libera y vacía la salida pendiente del búfer de un escritor. Olvidar el cierre puede agotar los límites de archivos abiertos, perder texto almacenado en el búfer o impedir que otro programa modifique el archivo.

Declara los recursos en la cabecera de try

import java.io.BufferedReader;
import java.io.IOException;
import java.nio.charset.StandardCharsets;
import java.nio.file.Files;
import java.nio.file.Path;

class Lines {
    static void show(Path file) throws IOException {
        try (BufferedReader in =
                Files.newBufferedReader(file, StandardCharsets.UTF_8)) {
            String line;
            while ((line = in.readLine()) != null) {
                System.out.println(line);
            }
        }
    }
}

La cabecera abre el lector. El cuerpo lo usa y Java lo cierra cuando el cuerpo termina normalmente, retorna o lanza una excepción. No se necesita un finally separado. Aquí no hay ningún manejador, por lo que cualquier fallo comprobado sigue pasando a quien llama mediante throws IOException.

Un recurso debe implementar AutoCloseable. Esa interfaz declara close() y permite Exception; su subinterfaz Closeable restringe el fallo comprobado declarado a IOException. Los lectores, escritores y Scanner cumplen el requisito. Un String no. Las variables de la cabecera son implícitamente final y están disponibles en el cuerpo, no en los bloques catch o finally de esa sentencia. Java 9 y posteriores también permiten una variable existente final o efectivamente final: try (in) { ... }.

Cierra en orden inverso

Separa los recursos con puntos y coma:

try (BufferedReader in = Files.newBufferedReader(source);
     java.io.BufferedWriter out = Files.newBufferedWriter(target)) {
    String line;
    while ((line = in.readLine()) != null) {
        out.write(line);
        out.newLine();
    }
}

Este es un bloque dentro de un método que declara IOException, con rutas source y target distintas. Java abre primero in, luego out, y cierra out antes que in. Si falla la apertura de out, el lector ya abierto también se cierra. Abrir un escritor sobre la ruta de entrada truncaría esa entrada, por lo que las rutas deben ser distintas para esta copia directa.

El cierre de recursos ocurre antes de las cláusulas catch y finally que pertenecen a la misma sentencia. Esos manejadores pueden recibir fallos de apertura, uso o cierre de los recursos.

Mantén visible el fallo principal

Supón que el cuerpo lanza una excepción de registro y después el cierre del lector lanza una IOException. Try-with-resources propaga la excepción del cuerpo y adjunta el fallo de cierre como suprimido. getSuppressed() lo recupera y la traza imprime una sección Suppressed:. El fallo original del cuerpo permanece visible. Si el cuerpo tiene éxito y solo falla el cierre, la excepción de cierre se propaga normalmente.

Si se producen varios fallos durante el cierre, Java sigue intentando cerrar los recursos restantes. En cambio, un simple finally { resource.close(); } puede sustituir un fallo pendiente del cuerpo por uno de limpieza.

Usa este patrón para los recursos de archivos de los que tu código es responsable. Cerrar un scanner sobre System.in también cierra la entrada de teclado del programa e impide lecturas posteriores. Mantén la responsabilidad de la entrada estándar compartida a nivel del programa en vez de cerrarla en un método auxiliar.

La lectura te proporciona texto. El análisis da significado a ese texto: un recuento, una edad o un objeto. Mantén separadas estas dos operaciones para que un registro incorrecto no parezca un fallo de lectura del archivo.

Elige cuánto mantener en memoria

Importa java.nio.file.Files y Path, además de los tipos de lector o colección que utilices. Los métodos de texto de Files usan UTF-8 de forma predeterminada. Un BufferedReader debe usarse en try-with-resources e informa de los fallos de lectura con IOException. Leer una línea cada vez evita mantener toda la entrada en memoria, salvo que tu procesamiento almacene después todos los registros.

Un scanner también necesita cerrarse y requiere una comprobación adicional de fallos:

import java.io.IOException;
import java.nio.charset.StandardCharsets;
import java.nio.file.Path;
import java.util.Scanner;

class ScanFile {
    static void show(Path file) throws IOException {
        try (Scanner sc = new Scanner(file, StandardCharsets.UTF_8)) {
            while (sc.hasNextLine()) {
                System.out.println(sc.nextLine());
            }
            if (sc.ioException() != null) throw sc.ioException();
        }
    }
}

La apertura puede lanzar una excepción directamente. Durante la lectura, Scanner trata un fallo subyacente de entrada y salida como el final de la entrada y lo almacena; ioException() permite consultarlo. Sin esa comprobación final, una lectura parcial puede parecer satisfactoria.

Cuenta las líneas físicas y después analiza

Para las líneas de entrada «12», «15», «abc», una línea vacía y «9», incrementa el número de línea antes de decidir si omites una línea en blanco. Convierte cada línea que no esté en blanco con Integer.parseInt(line.trim()) dentro de su propio try. Informa «Line 3: not a number: abc» y continúa. La suma válida es 36 y el recuento es 3, lo que da una media de 12,0. Calcula (double) sum / count para conservar un resultado fraccionario y comprueba primero que el recuento no sea cero.

Comprueba los campos antes de acceder por índice

Los datos sencillos separados por comas pueden convertirse en objetos. Aquí la primera línea es un encabezado obligatorio; cada registro restante tiene un nombre no vacío y una edad entera:

String[] parts = line.split(",", -1);
if (parts.length != 2 || parts[0].isBlank() || parts[1].isBlank()) {
    System.out.println("Line " + lineNumber + ": expected name and age");
    continue;
}
try {
    int age = Integer.parseInt(parts[1].trim());
    people.add(new Person(parts[0].trim(), age));
} catch (NumberFormatException e) {
    System.out.println("Line " + lineNumber + ": invalid age");
}

Este fragmento del cuerpo de un bucle presupone line, lineNumber, un List<Person> llamado people y un constructor Person(String, int). Omite el encabezado «name,age» antes de este paso de análisis; de lo contrario, «age» falla en la conversión numérica. Los registros «Ana,34», «Ben,29» y «Chen,41» suman 104 años y tienen una media aproximada de 34,67.

Un simple split(",") descarta los campos vacíos finales: «Eve,» produce una sola parte. El límite -1 conserva el segundo campo vacío para que la validación pueda notificarlo. Comprueba siempre la longitud antes de parts[1]. Dividir por sí solo no maneja las comas entre comillas, como la del nombre en ""Smith, Ana",34"; el CSV completo necesita un analizador CSV.

Abrir un archivo de salida puede modificarlo de inmediato. Elige entre sustituir o añadir al final antes de abrir el escritor y termina cerrándolo para que la salida almacenada en el búfer no quede en memoria.

Sustituye o añade al final

Files.writeString(path, text) escribe una cadena. Files.write(path, lines) escribe un iterable de líneas y añade el separador de línea del sistema después de cada una, incluida la última. Con sus opciones predeterminadas, ambos crean un archivo inexistente y truncan uno existente.

import java.io.IOException;
import java.nio.charset.StandardCharsets;
import java.nio.file.Files;
import java.nio.file.Path;
import java.nio.file.StandardOpenOption;

class RunLog {
    static void recordStart(Path log) throws IOException {
        Files.writeString(log, "started" + System.lineSeparator(),
            StandardCharsets.UTF_8,
            StandardOpenOption.CREATE, StandardOpenOption.APPEND);
    }
}

CREATE permite crear un archivo nuevo; APPEND conserva el contenido anterior y añade al final. APPEND por sí solo falla si el archivo no existe. Añadir al final no inserta un separador ausente antes de tu texto: si un archivo existente termina a mitad de una línea, los siguientes caracteres continúan esa línea.

La clase más antigua FileWriter tiene un indicador de adición: new FileWriter("log.txt", StandardCharsets.UTF_8, true). Sin adición al final, un nuevo FileWriter o un PrintWriter creado con un nombre de archivo también trunca un archivo existente. Nunca abras un escritor que sustituya el contenido sobre una entrada que aún necesites leer.

Elige un escritor y detecta los fallos

BufferedWriter admite write y newLine(), e informa de los fallos de escritura como excepciones comprobadas:

import java.io.BufferedWriter;
import java.io.IOException;
import java.nio.charset.StandardCharsets;
import java.nio.file.Files;
import java.nio.file.Path;
import java.util.Locale;

class ReportWriter {
    static void write(Path file) throws IOException {
        try (BufferedWriter out =
                Files.newBufferedWriter(file, StandardCharsets.UTF_8)) {
            out.write("Readings: 3");
            out.newLine();
            out.write(String.format(Locale.ROOT, "Average: %.2f", 3.0));
            out.newLine();
        }
    }
}

El archivo tiene dos líneas: «Readings: 3» y «Average: 3.00». Locale.ROOT fija el punto decimal. newLine(), println y %n usan el fin de línea de la plataforma; un \n literal escribe LF en todos los sistemas.

Un PrintWriter ofrece los prácticos print, println y printf, pero esos métodos registran los fallos de entrada y salida en vez de lanzarlos. checkError() vacía el búfer e informa de su indicador de error. Para comprobar también los fallos del cierre final, conserva el acceso al escritor y comprueba después de cerrarlo. Para código que deba propagar de forma fiable los fallos de escritura, usa BufferedWriter o los métodos de Files.

Completa el ciclo de escritura y lectura

Los escritores almacenan la salida en un búfer. flush() envía el texto pendiente; close() vacía el búfer y libera el archivo. Try-with-resources garantiza que se intente el cierre en cada salida, pero no puede hacer que una escritura en disco tenga éxito.

Para guardar una persona, escribe el nombre, una coma y la edad entera, seguidos de un fin de línea. Da formato a los decimales con Locale.ROOT para que un Double.parseDouble posterior pueda leerlos. Una carpeta superior inexistente no se crea al abrir un archivo: usa Files.createDirectories(folder) cuando se pretenda crearla o informa del fallo. Una escritura puede fallar después del truncamiento o de una salida parcial; usa una salida temporal y un movimiento atómico cuando debas proteger el destino.

Un procesador de archivos robusto necesita dos niveles de recuperación. Un registro incorrecto puede omitirse y notificarse; un fallo al leer o guardar el archivo detiene la tarea. Calcula un resultado completo antes de tocar su destino.

Lee, valida, calcula y guarda

El programa completo siguiente lee el encabezado opcional «date,temperature» seguido de registros sencillos de dos campos. Las fechas son etiquetas no vacías; las temperaturas son números finitos en grados Celsius. Omite y notifica los registros mal formados, incluidas las líneas en blanco. La excepción comprobada anidada mantiene separados los problemas de registros de los problemas de archivos.

import java.io.IOException;
import java.nio.charset.StandardCharsets;
import java.nio.file.AtomicMoveNotSupportedException;
import java.nio.file.Files;
import java.nio.file.NoSuchFileException;
import java.nio.file.Path;
import java.nio.file.StandardCopyOption;
import java.util.List;
import java.util.Locale;

public class TemperatureReport {
    static class InvalidRecordException extends Exception {
        InvalidRecordException(String message) { super(message); }
        InvalidRecordException(String message, Throwable cause) {
            super(message, cause);
        }
    }

    static List<String> readLines(Path file) throws IOException {
        return Files.readAllLines(file, StandardCharsets.UTF_8);
    }

    static double parseTemperature(String line, int lineNumber)
            throws InvalidRecordException {
        String[] parts = line.split(",", -1);
        if (parts.length != 2 || parts[0].isBlank()
                || parts[1].isBlank()) {
            throw new InvalidRecordException("Line " + lineNumber
                + ": expected a date label and a temperature");
        }
        try {
            double value = Double.parseDouble(parts[1].trim());
            if (!Double.isFinite(value)) {
                throw new InvalidRecordException("Line " + lineNumber
                    + ": temperature must be finite");
            }
            return value;
        } catch (NumberFormatException e) {
            throw new InvalidRecordException("Line " + lineNumber
                + ": not a number: " + parts[1], e);
        }
    }

    static String summarize(List<String> lines) {
        int count = 0;
        int skipped = 0;
        double sum = 0;
        double min = Double.POSITIVE_INFINITY;
        double max = Double.NEGATIVE_INFINITY;
        for (int i = 0; i < lines.size(); i++) {
            String line = lines.get(i);
            if (i == 0 && line.equals("date,temperature")) continue;
            try {
                double value = parseTemperature(line, i + 1);
                sum += value;
                count++;
                min = Math.min(min, value);
                max = Math.max(max, value);
            } catch (InvalidRecordException e) {
                skipped++;
                System.err.println(e.getMessage());
            }
        }
        if (count == 0) {
            return String.format(Locale.ROOT,
                "No valid readings%nSkipped lines: %d%n", skipped);
        }
        return String.format(Locale.ROOT,
            "Valid readings: %d%nAverage (°C): %.2f%n"
                + "Minimum (°C): %.2f%nMaximum (°C): %.2f%n"
                + "Skipped lines: %d%n",
            count, sum / count, min, max, skipped);
    }

    static void writeSummary(Path file, String text) throws IOException {
        Path target = file.toAbsolutePath();
        Path temp = Files.createTempFile(target.getParent(), "report-", ".tmp");
        try {
            Files.writeString(temp, text, StandardCharsets.UTF_8);
            Files.move(temp, target, StandardCopyOption.ATOMIC_MOVE);
        } catch (IOException e) {
            try {
                Files.deleteIfExists(temp);
            } catch (IOException cleanup) {
                e.addSuppressed(cleanup);
            }
            throw e;
        }
    }

    public static void main(String[] args) {
        Path input = Path.of("readings.csv");
        Path output = Path.of("summary.txt");
        try {
            List<String> lines = readLines(input);
            String report = summarize(lines);
            writeSummary(output, report);
            System.out.println("Saved: " + output.toAbsolutePath());
        } catch (NoSuchFileException e) {
            System.err.println("File or folder not found: " + e.getFile());
        } catch (AtomicMoveNotSupportedException e) {
            System.err.println("Could not save atomically: "
                + output.toAbsolutePath());
        } catch (IOException e) {
            System.err.println("Could not process " + input.toAbsolutePath()
                + " or save " + output.toAbsolutePath() + ": " + e.getMessage());
        }
    }
}

Sigue una ejecución

Usa estas cinco líneas de entrada sin encabezado:

2026-03-01,4.5
2026-03-02,6.0
2026-03-03,abc
2026-03-04,-1.5
missing comma

Las líneas 1, 2 y 4 producen tres lecturas válidas. La suma es 9,0; la media es 3,00 °C, la mínima es -1,50 °C y la máxima es 6,00 °C. Las líneas 3 y 5 producen mensajes de diagnóstico y el informe registra dos líneas omitidas. El manejador de análisis está dentro del bucle, por lo que cada registro incorrecto deja accesibles los registros posteriores. Actualizar los totales solo después de un análisis correcto mantiene fuera los valores rechazados.

Double.parseDouble acepta cadenas especiales como «NaN» e «Infinity». Double.isFinite las rechaza aquí porque no pueden servir como temperaturas medidas normales. Un archivo vacío, un archivo con solo encabezado o registros todos no válidos llegan a la rama de recuento cero antes de la división o del uso de la mínima y la máxima iniciales.

Protege el destino

La lectura y el cálculo terminan antes de que comience el guardado. Files.writeString abre y cierra su propio archivo, pero puede fallar después de escribir una parte. Por eso el programa escribe en un archivo temporal de la carpeta de destino, lo cierra y solicita ATOMIC_MOVE. El movimiento hace visible el resultado terminado como una sola operación del sistema de archivos cuando se admite.

La sustitución atómica de un destino existente depende de la implementación. El programa informa de un movimiento o sustitución no admitidos y nunca lo reintenta con un movimiento no atómico. Un fallo de limpieza se adjunta a la excepción original en lugar de sustituirla. La visibilidad atómica no garantiza la supervivencia a un corte de energía.

Comprobar Files.exists(input) de antemano no puede garantizar la lectura posterior: un archivo puede desaparecer o volverse inaccesible después de la comprobación. Maneja la operación real. Antes de confiar en un procesador, pruébalo con una entrada inexistente, carpetas de salida inexistentes, archivos vacíos y con solo encabezado, fines de línea CRLF, texto acentuado y registros mal formados. Los mensajes al usuario deben nombrar la ruta que falló; depurar una excepción envoltorio también requiere su causa original y su traza de la pila.