Demo: finding a swallowed exception

Written Explanation

The symptom

A swallowed exception shows up as absence: no error, no crash, and wrong or empty results. Typical reports sound like:

• "The welcome screen shows no name."
• "The report is blank, but there was no error."
• "Some orders never arrive, and the logs are clean."

Compare with lesson 1: an unhandled exception is loud and tells you the type, message, and line. A swallowed one has been silenced on purpose, so the usual starting point of reading the trace is missing. You have to look for the place where the trace would have come from.

The hunt, step by step

1. Reproduce. Run the program in the failing situation (here: the file is missing). Note exactly what you see, and what you expected to see.
2. Narrow down. Find the code that produces the wrong value. Work backward from the visible symptom: where does the empty name come from?
3. Search for suspects. Look for catch blocks near it, especially those with an empty body, with only a comment, with a return of a default value, or catching Exception or Throwable. Your editor's search or the command line can find the word catch across the project.
4. Confirm. Temporarily print something in the block, or step through with the debugger (BEG-018). If it runs in your failing scenario, you have the culprit.
5. Fix it properly (below), and re-run the same scenario to see the problem reported.

The program under suspicion

import java.nio.file.Files;
import java.nio.file.Path;

public class V0 {
    static String loadName(Path path) {
        try {
            return Files.readString(path).trim();
        } catch (Exception e) {
        }
        return "";
    }

    public static void main(String[] args) {
        String name = loadName(Path.of("user.txt"));
        System.out.println("Welcome, " + name + "!");
    }
}

With no user.txt in the folder, real output:

Welcome, !

No error and no clue. The empty catch swallowed a NoSuchFileException, and the method returned "" as if nothing had happened. The caller cannot tell "the user's name is empty" from "the file is missing".

Why the empty catch is dangerous

It does three bad things at once:

• It hides the problem from the user and from the logs.
• It hands a wrong value onward (""), which can corrupt later results, so the damage appears far from the cause.
• It catches Exception, so it would also hide bugs that have nothing to do with files, such as a NullPointerException in the same try.

The tempting half-fix: printStackTrace only

The quickest "fix" is to fill the block with e.printStackTrace();. It is better than silence, but still wrong in a program that must work. Here is a truncated real run (the lines inside the JDK vary with the operating system and version, so some are replaced by ...):

java.nio.file.NoSuchFileException: user.txt
	at java.base/sun.nio.fs.WindowsException.translateToIOException(WindowsException.java:85)
	...
	at java.base/java.nio.file.Files.readString(Files.java:3346)
	at V1.loadName(V1.java:7)
	at V1.main(V1.java:15)
Welcome, !

What is wrong with it?

• The program still carries on and still prints Welcome, !. The caller is still handed a wrong answer.
• The trace goes to the error output, which a real user never sees, and in a server it may go to a place nobody checks.
• It still catches the broad Exception.
• It looks like handling, so a reviewer may stop worrying about it.

Printing the trace is a debugging aid, not a plan.

The proper fix

A good catch block does at least one of three things, on purpose:

And it uses the narrowest type, here IOException, instead of Exception. Applying that to our program:

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

public class V2 {
    static String loadName(Path path) {
        try {
            return Files.readString(path).trim();
        } catch (IOException e) {
            throw new IllegalStateException("Could not load the user name from " + path, e);
        }
    }

    public static void main(String[] args) {
        try {
            String name = loadName(Path.of("user.txt"));
            System.out.println("Welcome, " + name + "!");
        } catch (IllegalStateException e) {
            System.out.println("Cannot start: " + e.getMessage());
            System.out.println("Reason: " + e.getCause());
        }
    }
}

Real output with no file, then with a user.txt containing Sara:

Cannot start: Could not load the user name from user.txt
Reason: java.nio.file.NoSuchFileException: user.txt
Welcome, Sara!

loadName cannot decide what the user sees, so it rethrows a clearer exception with the original as cause, and main (the code that talks to the user) reports it. The wrong value "" no longer flows onward, and other kinds of exceptions (bugs) are not hidden anymore because the catch is narrow.

When ignoring an exception is acceptable

Rarely, ignoring is right: for example when closing something quietly after the real work has succeeded and a second failure changes nothing for the user. In those cases, name the variable ignored and write a comment saying why, so the next reader sees it was deliberate:

} catch (IOException ignored) {
    // The data was already saved; a failure while closing the preview changes nothing.
}

If you cannot write a convincing comment, the catch is not intentional, and it should not be empty. (Naming it ignored is a widely used convention, not a language rule.)