Exceptions and Files in Java

An exception is an object describing a problem that interrupts a running program. Throwing it stops the current statement. Java skips the remaining normal work until it finds a matching handler; without one, the exception passes back through the methods that called it.

Recognize the kind of problem

A missing semicolon is a compile-time error: the program cannot compile. An exception occurs when compiled code runs with data that triggers a problem.

Array indexes start at 0, so length 3 means valid indexes 0, 1 and 2. Floating-point division follows different rules: 10.0 / 0 produces Infinity; it does not throw the integer-division exception.

Read a trace from the top

Here is a complete class, with no blank lines before the first line:

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));
    }
}

The array is empty, so its length is 0. The division on line 5 fails. The trace is:

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

1. Read the first line for the exception class and message.
2. Read the top at frame for the point where the problem was detected.
3. Read downward for callers: main called average on line 9.
4. If the top frames belong to Java's library, find the first frame naming your own class. For a failed Integer.parseInt, library frames can precede the call in your code.

The trace follows the call stack, the chain of active method calls. It tells you where to investigate, but the bad value may have been created earlier. Here the division detects the problem; the caller supplied the empty array. Decide whether an empty input should be rejected or handled before computing an average.

Inspect the exception object

e.getMessage() returns the message and can return null. e.toString() includes the class name and, when present, the message. e.printStackTrace() prints the trace to standard error. A Caused by: section shows an earlier exception retained inside a wrapper.

JVM-generated NullPointerException messages normally identify the null expression. An explicitly created exception can instead have a custom message or none. Follow the reference back to where it should have received an object.

An unhandled exception leaving main ends the main thread; that ends a single-threaded program. Fix bugs such as wrong indexes in the code. Plan recovery for expected external problems, such as a missing file or invalid user input.

Exception classes use the inheritance rules you already know. A thrown subclass object also belongs to its superclass, which explains both Java's exception categories and how a handler matches them.

Follow the hierarchy

Only objects of Throwable or its subclasses can be thrown. Two main branches sit below it:

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

Error describes serious failures of the running environment. An ordinary application should not try to recover from an exhausted heap or a stack exhausted by endless recursion. Exception describes problems an application may handle, including its RuntimeException branch.

Both kinds are thrown at run time. The word "checked" describes the compiler checking your handling, not an earlier moment when the failure occurs. Unchecked also does not mean harmless: an unhandled null reference can stop a program.

Apply catch or declare

Reading a file can fail even in correct code. A helper can leave the decision to its caller:

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 can throw the checked IOException. The declaration passes that possibility to the caller, which must catch it or declare it too. Removing throws IOException without adding a handler makes the helper fail compilation. A method using Integer.parseInt has no comparable compiler obligation because NumberFormatException is unchecked.

Checked failures often describe conditions a caller can plan for, such as a file disappearing. Runtime failures often identify bugs or invalid arguments. These are useful design reasons, but the superclass chain determines the category. A custom class extending RuntimeException remains unchecked even when a caller could recover.

Match handlers through inheritance

catch (IOException e) can handle a FileNotFoundException or NoSuchFileException. catch (Exception e) also catches runtime exceptions; it can turn a coding bug into a misleading input message. catch (Throwable e) reaches the Error branch too and is rarely appropriate for ordinary recovery.

To classify an unfamiliar class, trace its inheritance upward in the API documentation. InputMismatchException extends NoSuchElementException, which extends RuntimeException, so it is unchecked. InterruptedException extends Exception outside the runtime branch, so it is checked. Declaring an unchecked type in a throws clause is allowed, but does not change its category.

A try block marks work that may fail. A matching catch block gives the program a useful next action, such as asking for another value. Handling the exception does not retry the failed statement by itself.

Trace the branches

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");

The output is A, B, D: For input string: "4x", and E, each on its own line. The conversion fails, so Java skips C and enters the matching handler. When that handler finishes normally, execution continues after the whole statement. If conversion succeeds, the handler is skipped. If the block throws an ArithmeticException, this handler does not match; that exception propagates.

Retry with fresh input

Read an entire line before converting it. The loop below accepts a whole number and handles the end of keyboard input by reporting that no value was supplied:

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");
    }
}

For inputs "twenty" and "20", the handler prints once, the loop reads a new line, and the method returns 20. trim() removes surrounding whitespace: Integer.parseInt(" 20") otherwise fails. The conversion accepts an optional sign and digits representing an in-range integer.

A token-based scanner needs a different repair. When nextInt() meets "ten", its InputMismatchException leaves that token unread. Catching and calling nextInt() again repeats the failure forever. Consume the bad token with next() or discard the line with nextLine() before retrying. hasNextInt() can check a token before conversion.

Keep the recovered state usable

A variable declared inside try exists only in that block. If later code needs the result, declare it outside and make every continuing path assign a valid value:

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

Zero is appropriate here only if the program defines it as a valid fallback. Leaving quantity unassigned in the handler causes a compile-time definite-assignment error.

Catch the narrow type you can handle. An empty handler silently loses the problem; a broad catch (Exception e) can label a null-reference bug as a bad number. Recovery should ask again, skip one item, choose a valid default, report failure, or pass a meaningful exception onward. For simple predictable boundaries, check first: index >= 0 && index < list.size() prevents both negative and too-large list indexes.

A file can be missing, unreadable, or full of malformed records. Those failures need different responses. Several handlers let one try distinguish them, while the block's position decides how much work stops when something fails.

Put specific handlers first

Java tests handlers from top to bottom and runs the first matching one. It does not keep running later handlers for the same exception.

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 extends IOException, so it must come first. Reversing them makes the specific handler unreachable and prevents compilation. The conversion exception is unrelated to IOException, so those two handlers can appear in either order.

A checked handler must also be relevant to the protected work. Catching IOException around only int count = 5; is rejected because that block cannot throw it. This restriction does not apply in the same way to unchecked types or the broad Exception and Throwable types.

Share a handler when the response is shared

A multi-catch joins unrelated exception types with |:

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());
}

Here the missing second field triggers the index exception. A present but nonnumeric field would trigger the conversion exception, and both receive the same response. The multi-catch parameter is implicitly final. Alternatives cannot be a subclass and its superclass: FileNotFoundException | IOException is invalid because IOException already covers both.

Decide what one failure should skip

Consider the texts "3", "x", and "5". With a try around the whole loop, processing stops at "x" and the sum so far is 3. Put the try inside the loop to recover separately for each item:

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);

This prints Skipped: x and then 8. The loop continues because its body handled that record's failure. Nested handlers search outward from the innermost protected block; a nonmatching inner handler leaves an outer one a chance. Choose the smallest unit of work that should fail together: one record for bad data, the file operation for a read failure.

Some work must happen whether an operation succeeds or fails. A finally block runs as control leaves its try statement, including when an exception propagates or a method returns.

Follow an unmatched exception

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");

Only 1 and 4 print before the ArrayIndexOutOfBoundsException propagates. Index 2 is outside the two-element array. The handler does not match, but finally still runs. The statement printing 5 is outside the cleanup block, so the propagating exception skips it.

If the protected work instead throws a matching NumberFormatException after printing 1, the handler prints 3, cleanup prints 4, and execution continues to 5. On a successful path, no handler runs, but cleanup still does.

Return values are prepared before cleanup

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

The return expression is evaluated first. Java then prints cleanup, and the caller receives 1. A break or continue leaving a protected region also runs its cleanup before the control transfer takes effect.

Keep return out of finally. A return 2; there would replace the pending return value and could even discard a pending exception. An exception thrown by cleanup can likewise replace the original failure. Cleanup should not introduce a second competing result. The compiler's -Xlint:finally option warns when a finally block cannot complete normally.

Close an object only if it opened

The older manual pattern needs a variable visible to the cleanup block:

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();
        }
    }
}

If opening fails, sc is still null, so the guard prevents cleanup from throwing a new null-reference exception. For closeable objects, try-with-resources removes this bookkeeping and handles competing failures more safely.

finally is not a guarantee against the machine stopping. System.exit ends the JVM without running this cleanup; a crash or power loss also prevents it. An infinite loop that never leaves the block never reaches its finally either.

Your methods can reject invalid requests before changing an object. Choose an exception that identifies the problem and lets the caller respond.

Throw an object now

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;
    }
}

Calling setPercentage(120) throws with the message percentage must be 0 to 100, was 120. The assignment has not run, so the field retains its previous value. This is failing fast: report the invalid request at the point where you can explain it. The same check in a constructor prevents an invalid object from being returned.

throw needs an exception object, as in throw new IllegalArgumentException("bad quantity");. A class name alone is not an object. An ordinary statement directly after an unconditional throw in the same block is unreachable.

Objects.requireNonNull(name, "name must not be null"), from java.util.Objects, is a convenient null check. An already-sent order rejecting another item is a state problem; a negative item quantity is an argument problem.

Declare what can leave the method

A file-reading helper can declare its checked failure:

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 is an executable statement. throws belongs to the method declaration and tells callers what checked failures they must address. It neither catches a failure nor makes the method continue after one. Each caller must catch IOException or declare it in turn. A catch can also rethrow the same object with throw e;.

Catch where a useful response is possible. A helper usually cannot ask the user to select a different file, but main can. Printing "error" and returning an empty list would confuse a missing file with a genuinely empty file. A small experiment may let main declare throws IOException; a finished program handles expected failures with useful messages. Unchecked types may be declared for documentation even though the compiler does not require them.

Respect the inherited contract

If an interface declares read() throws IOException, an override may declare IOException, a narrower checked subclass, or no checked exception. It cannot broaden the declaration to Exception. It can declare unchecked types. An override of Object.toString() cannot add IOException, since the inherited method declares no checked exceptions. Calls through the interface type must still address its declared IOException, even when one implementation declares none.

A standard exception is often enough. Create a custom class when callers need to recognize a problem specific to the program, such as insufficient stock or a malformed data record, and respond differently to it.

Choose the superclass deliberately

Extending Exception creates a checked exception. Extending RuntimeException creates an unchecked exception. Use the checked design when callers should plan for a recoverable domain failure; use the unchecked design for misuse or a programming bug.

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

super(message) stores the message in the inherited exception machinery, so getMessage() returns it. The class name conventionally ends in Exception. Extra fields and getters can expose structured details such as requested and available counts.

Leave stock unchanged after failure

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);
    }
}

Starting with 12 pens, removing 5 leaves 7. A later request for 10 throws, and 7 remain because the update comes after all checks. The caller must handle or declare the checked stock failure; the invalid-quantity failure is unchecked. A program needing a distinct unknown-item response could use a related UnknownItemException, with both domain types under an InventoryException base class.

Wrap without losing the original problem

A parser can translate a low-level conversion failure into a record-level failure:

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

Inside the parsing method, a handler can do this:

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

The wrapper gives the caller a meaningful category and line number. Its getCause() returns the original NumberFormatException, and a printed trace retains a Caused by: section. Building a new exception with only the old message loses the original object and its trace.

java.io.UncheckedIOException is a ready-made unchecked wrapper specifically for IOException. Its constructors accept the cause, with an optional message. It can carry a file failure through an override that cannot add a checked declaration. Wrapping changes the type the caller sees; it does not repair the file problem. Keep ordinary loop decisions as conditions and break, without inventing exceptions for routine flow.

A file stores bytes, while your program works with characters and numbers. A successful read needs the right location, the right character encoding, and a clear convention for lines and numeric text.

Find the actual location

A relative path starts from the program's working directory. It does not start from the folder holding the source code. An absolute path starts from the file-system root, such as /home/ana/data/scores.txt, or a drive root on 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());

Import java.nio.file.Path. Creating this Path opens nothing and checks no existence. toAbsolutePath() reveals where Java will look, and getFileName() gives scores.txt. An IDE often uses the project folder as the working directory. Forward slashes in "data/scores.txt" work on Windows, Linux and macOS. A Windows path literal using backslashes needs escaping, as in "C:\\data\\scores.txt". The older java.io.File represents a location too; convert with toPath() or toFile().

Match bytes to characters

UTF-8 encodes every Unicode character. Basic Latin characters take one byte; others take two to four. The text "café" contains four characters but five UTF-8 bytes because "é" takes two. Reading those bytes as ISO-8859-1 can produce "café". Use the encoding the writer used.

The text methods of Files default to UTF-8. Classes such as FileWriter and a scanner opened without a charset use the default charset, which became UTF-8 in Java 18; older installations can differ. StandardCharsets.UTF_8, from java.nio.charset, makes the choice explicit. Invalid bytes read by Files.readAllLines produce MalformedInputException, an IOException subclass.

Read lines without leftover endings

With a terminator after each line, "a" and "b" need four bytes with LF endings and six with CRLF endings. BufferedReader.readLine(), Files.readAllLines, and Scanner.nextLine() remove recognized line endings. Splitting a complete string with split("\n") leaves the Windows \r, so converting "12\r" with parseInt fails. Prefer line-reading methods, or trim the text. System.lineSeparator() and formatting %n produce the current system's ending.

Keep numeric files consistent

Integer.parseInt accepts integer text, with no decimal separator. Double.parseDouble("3.5") accepts a period; Double.parseDouble("3,5") fails. These parsing methods ignore locale. Scanner numeric methods and ordinary decimal formatting follow locale, so German or Dutch settings may expect "3,5" and produce "3,50". Use scanner.useLocale(Locale.ROOT) and String.format(Locale.ROOT, "%.2f", value) for period-decimal data; import java.util.Locale.

Missing locations commonly produce NoSuchFileException with Files or Scanner(Path), while older file-name constructors can give FileNotFoundException. Permission failures can give AccessDeniedException. These are checked I/O failures: a correct path expression alone cannot prevent them.

An open file uses an operating-system resource. Closing releases it and flushes a writer's pending output. A forgotten close can exhaust open-file limits, lose buffered text, or leave another program unable to change the file.

Declare resources in the try header

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);
            }
        }
    }
}

The header opens the reader. The body uses it, and Java closes it when the body ends normally, returns, or throws. No separate finally is needed. There is no handler here, so any checked failure still passes to the caller through throws IOException.

A resource must implement AutoCloseable. That interface declares close() and permits Exception; its Closeable subinterface narrows the declared checked failure to IOException. Readers, writers, and Scanner qualify. A String does not. Header variables are implicitly final and are available in the body, not in that statement's catch or finally blocks. Java 9 and later also allow an existing final or effectively final variable: try (in) { ... }.

Close in reverse order

Separate resources with semicolons:

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();
    }
}

This is a block inside a method declaring IOException, with distinct source and target paths. Java opens in first, then out, and closes out before in. If opening out fails, the already-open reader is still closed. Opening a writer on the input path would truncate that input, so the paths must differ for this direct copy.

Resource closing happens before catch and finally clauses belonging to the same statement. Those handlers can receive failures from opening, using, or closing the resources.

Keep the main failure visible

Suppose the body throws a record exception, then closing the reader throws an IOException. Try-with-resources propagates the body exception and attaches the closing failure as suppressed. getSuppressed() retrieves it, and the trace prints a Suppressed: section. The original body failure stays visible. If the body succeeds and closing alone fails, the closing exception propagates normally.

With multiple failures during closing, Java still attempts the remaining closes. A plain finally { resource.close(); } can instead replace a pending body failure with a cleanup failure.

Use this pattern for file resources your code owns. Closing a scanner on System.in also closes the program's keyboard input, preventing later reads. Keep ownership of shared standard input at the program level instead of closing it in a helper.

Reading gives you text. Parsing gives that text a meaning: a count, an age, or an object. Keep those two operations separate so a bad record does not look like a failed file read.

Choose how much to hold in memory

Import java.nio.file.Files and Path, plus the reader or collection types you use. Files text methods default to UTF-8. A BufferedReader belongs in try-with-resources and reports reading failures with IOException. Reading one line at a time avoids holding the entire input in memory, unless your processing stores all the records afterward.

A scanner also needs closing, and one extra failure check:

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();
        }
    }
}

Opening can throw directly. During reading, Scanner treats an underlying I/O failure as end of input and stores it; ioException() exposes it. Without that final check, a partial read can look successful.

Count physical lines, then parse

For input lines "12", "15", "abc", an empty line, and "9", increment the line number before deciding whether to skip a blank. Convert each nonblank line with Integer.parseInt(line.trim()) inside its own try. Report "Line 3: not a number: abc" and continue. The valid sum is 36 and count is 3, giving average 12.0. Compute (double) sum / count to preserve a fractional result, and check that the count is not zero first.

Check fields before indexing

Simple comma-separated data can become objects. Here the first line is a required header; each remaining record has a nonempty name and integer age:

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");
}

This loop-body fragment assumes line, lineNumber, a List<Person> named people, and a Person(String, int) constructor. Skip the header "name,age" before this parsing step; otherwise "age" fails numeric conversion. The records "Ana,34", "Ben,29", and "Chen,41" total 104 years and average about 34.67.

Plain split(",") drops trailing empty fields: "Eve," produces only one part. The -1 limit keeps the empty second field so validation can report it. Always check length before parts[1]. Splitting alone does not handle quoted commas, such as the name in ""Smith, Ana",34"; full CSV needs a CSV parser.

Opening an output file can change it immediately. Choose replacement or appending before opening the writer, and finish by closing it so buffered output is not left in memory.

Replace or append

Files.writeString(path, text) writes one string. Files.write(path, lines) writes an iterable of lines, adding the system line separator after each, including the last. With their default options, both create a missing file and truncate an existing one.

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 allows a new file; APPEND preserves old content and adds at the end. APPEND alone fails if the file is absent. Appending does not insert a missing separator before your text: if an existing file ends halfway through a line, the next characters continue that line.

The older FileWriter has an append flag: new FileWriter("log.txt", StandardCharsets.UTF_8, true). Without append, a new FileWriter or a file-name PrintWriter truncates an existing file too. Never open a replacing writer on input you still need to read.

Choose a writer and notice failures

BufferedWriter supports write and newLine(), and reports write failures as checked exceptions:

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();
        }
    }
}

The file has two lines: "Readings: 3" and "Average: 3.00". Locale.ROOT fixes the decimal point. newLine(), println, and %n all use the platform line ending; a literal \n writes LF on every system.

A PrintWriter offers convenient print, println, and printf, but those methods record I/O failures instead of throwing them. checkError() flushes and reports its error flag. When checking final close failures too, retain access to the writer and check after closing. For code that must reliably propagate writing failures, use BufferedWriter or the Files methods.

Complete the round trip

Writers buffer output. flush() sends pending text onward; close() flushes and releases the file. Try-with-resources ensures closing is attempted on every exit, but cannot make a disk write succeed.

To save a person, write the name, a comma, and the integer age, then a line ending. Format decimals with Locale.ROOT, so a later Double.parseDouble can read them. A missing parent directory is not created by opening a file: use Files.createDirectories(folder) when creating it is intended, or report the failure. A write can fail after truncation or partial output; use temporary output and an atomic move when the destination must be protected.

A robust file processor needs two recovery levels. A bad record can be skipped and reported; a failure to read or save the file stops the task. Compute a complete result before touching its destination.

Read, validate, compute, save

The complete program below reads optional header "date,temperature" followed by simple two-field records. Dates are nonempty labels; temperatures are finite numbers in degrees Celsius. It skips and reports malformed records, including blank lines. The nested checked exception keeps record problems separate from file problems.

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());
        }
    }
}

Follow one run

Use these five input lines without a header:

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

Lines 1, 2, and 4 produce three valid readings. The sum is 9.0; average is 3.00 °C, minimum is -1.50 °C, and maximum is 6.00 °C. Lines 3 and 5 produce diagnostics, and the report records two skipped lines. The parsing handler sits inside the loop, so each bad record leaves later records reachable. Updating totals only after successful parsing keeps rejected values out.

Double.parseDouble accepts special strings such as "NaN" and "Infinity". Double.isFinite rejects them here because they cannot serve as ordinary measured temperatures. An empty file, a header-only file, or all-invalid records reaches the count-zero branch before division or use of the initial minimum and maximum.

Protect the destination

The read and computation finish before saving begins. Files.writeString opens and closes its own file, but can fail after writing part of it. The program therefore writes to a temporary file in the destination folder, closes it, and requests ATOMIC_MOVE. The move makes the finished result visible as one file-system operation when supported.

Replacing an existing target atomically is implementation dependent. The program reports an unsupported move or replacement and never retries with a non-atomic move. A cleanup failure is attached to the original exception instead of replacing it. Atomic visibility does not promise survival of a power loss.

Checking Files.exists(input) beforehand cannot guarantee the later read: a file can disappear or become inaccessible after the check. Handle the actual operation. Before relying on a processor, try missing input, missing output folders, empty and header-only files, CRLF endings, accented text, and malformed records. User messages should name the failed path; debugging a wrapper also needs its original cause and stack trace.