Blog

A failed file read, an invalid number entered by a user, or a missing database record should not bring a Java program down with an unexplained stack trace. These failures have different causes, and Java provides different ways to deal with them. Good error handling begins with a simple idea: failure is part of normal program operation, not always proof that the application itself is broken.

For beginners, the hard part is rarely memorizing try and catch. It is deciding what to prevent, what to report to the caller, what can be recovered from, and when the current operation must stop safely.

Errors, exceptions, and failures are not all the same

Developers often use “error” for any unexpected event. Java is more specific. All throwable conditions inherit from Throwable, but the two branches that matter most are Exception and Error.

Category	Typical meaning	Usual response
Exception	A condition an application may reasonably anticipate or report	Handle, translate, or declare it
RuntimeException	A programming mistake or invalid assumption often discovered at runtime	Fix the cause; validate inputs where appropriate
Error	A serious JVM or environment problem, such as memory exhaustion	Usually do not catch it for normal recovery

IOException, for example, may occur when a file is unavailable or a storage device has a problem. It is a checked exception, so Java requires code to catch it or declare it with throws. NullPointerException is unchecked: the compiler does not require handling it. It often means code used a reference without first confirming that it pointed to an object.

Avoid catching Error or the broad Throwable in ordinary application code. Catching either can leave the application in an uncertain state and conceal serious conditions that should reach the runtime, monitoring system, or a top-level handler.

Prevent predictable failures before they happen

Exceptions are useful, but validation is usually clearer when input is expected to be unreliable. Web forms, command-line arguments, configuration files, and API requests can all contain missing or malformed values. Validate them near the boundary where they enter the application. That produces better messages and prevents invalid state from spreading.

public int parseAge(String text) {
    if (text == null || text.isBlank()) {
        throw new IllegalArgumentException("Age is required");
    }

    int age;
    try {
        age = Integer.parseInt(text.trim());
    } catch (NumberFormatException e) {
        throw new IllegalArgumentException("Age must be a whole number", e);
    }

    if (age < 0 || age > 130) {
        throw new IllegalArgumentException("Age must be between 0 and 130");
    }
    return age;
}

This separates format validation from range validation. The method does not assume an arbitrary string can represent an age; it rejects invalid input with a useful message that matches the domain.

Do not use exceptions for routine branching when a direct check is simple and expected. Checking whether input is blank or whether a map contains a key is usually clearer than deliberately causing and catching an exception. Exceptions fit failed operations, exceptional conditions, and invalid states that cannot be handled cleanly with an ordinary condition.

Checked and unchecked exceptions: choose deliberately

Checked exceptions extend Exception but not RuntimeException. Including one in a method signature makes the possible failure visible to callers:

public String loadSettings(Path path) throws IOException {
    return Files.readString(path);
}

The caller must either handle IOException or pass responsibility upward. That is useful when the caller has a meaningful recovery option, such as requesting another file location, using defaults, or retrying under controlled conditions.

Unchecked exceptions extend RuntimeException. They are often used for violated method contracts, invalid arguments, or impossible internal states. IllegalArgumentException suits a method called with a negative quantity when only positive values are valid. IllegalStateException suits an attempt to submit an order before required details have been supplied.

Create custom exceptions around meaningful boundaries

Custom exceptions help when built-in names do not describe the failure in application terms. A learning project might use InvalidConfigurationException; a payment-related service might use PaymentDeclinedException. The name should tell callers what failed without disclosing sensitive details.

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

Do not create a custom exception for every method. Too many narrow types make an API harder to use. Create one when callers need a different response, a domain term improves clarity, or a low-level failure needs to be translated into an application-level failure.

Keep try blocks small and catch blocks specific

A try block should cover the operation that may fail, rather than an entire method by default. A smaller scope makes the source of the exception easier to identify and avoids treating unrelated code as though it failed for the same reason.

Avoid this pattern:

try {
    connect();
    readSettings();
    calculateReport();
    saveReport();
} catch (Exception e) {
    System.out.println("Something went wrong");
}

The message provides almost no diagnostic value. It also treats connection, parsing, calculation, and storage failures as identical even though they may require different responses.

Instead, catch the most specific exception types that the current code can handle meaningfully:

try {
    String settings = Files.readString(configPath);
    applySettings(settings);
} catch (NoSuchFileException e) {
    useDefaultSettings();
} catch (IOException e) {
    throw new UncheckedIOException("Could not read configuration", e);
}

The first catch block has a real recovery path. The second keeps the original cause while translating a file-reading problem into a higher-level failure appropriate for this application layer.

When using multiple catch blocks, put more specific types before broader ones. Java rejects unreachable catch blocks, so IOException cannot appear before NoSuchFileException, one of its subclasses.

Preserve the cause when translating exceptions

Exception translation can make an API easier to understand. A repository class may catch SQLException and expose a domain-specific data-access exception instead. In most cases, attach the original exception as the cause.

try {
    return repository.findUserById(id);
} catch (SQLException e) {
    throw new UserDataAccessException(
        "Unable to load user record", e);
}

The second argument, e, preserves the exception chain. Logs and debuggers can then show both the higher-level message and details from the database driver. Dropping the cause makes production diagnosis much harder.

Messages should fit their audience. A user-facing message can safely say, “The settings file could not be loaded.” A detailed log may include the exception type, stack trace, request identifier, or operation name. Do not expose raw stack traces, database connection strings, filesystem paths, access tokens, or other sensitive internals to end users.

Always clean up resources with try-with-resources

Files, network connections, database statements, readers, writers, and streams can hold operating-system resources. Leaving them open can lead to file locks, connection exhaustion, incomplete writes, or failures that appear much later than the original mistake.

Use try-with-resources for objects that implement AutoCloseable:

try (BufferedReader reader = Files.newBufferedReader(path)) {
    return reader.readLine();
} catch (IOException e) {
    throw new UncheckedIOException("Could not read first line", e);
}

Java closes reader automatically when execution leaves the block, whether the method returns normally or throws an exception. This is safer and less repetitive than closing resources manually in a finally block.

A finally block still has a place when code must run regardless of success or failure, such as restoring temporary state or releasing a resource that cannot be used with try-with-resources. Keep it focused, and do not let cleanup code hide the original exception.

Do not swallow exceptions

An empty catch block is one of the most harmful beginner habits:

try {
    Files.delete(path);
} catch (IOException e) {
}

This code may report success even though the file was not deleted. The failure vanishes from logs, tests, and user feedback. Silent failures are particularly risky in security-related functions, backups, account updates, and configuration changes because the application may continue based on a false assumption.

Every catch block needs a purpose. Valid reasons include:

• Recovering with a safe fallback, such as loading default configuration.
• Adding context and rethrowing the failure.
• Returning a clearly documented result that represents an expected absence.
• Logging useful diagnostic information at the correct application boundary.
• Cleaning up or rolling back work before allowing the exception to continue.

If none of these applies, do not catch the exception at that layer. Let it propagate to code with enough context to decide what should happen next.

Use logging carefully, without exposing secrets

Logging is not the same as handling an exception. A program that logs an error and then continues with corrupted state has not recovered safely. First decide whether the operation can continue, then log the details as part of that response.

A useful log entry identifies the failed operation and includes the exception object so the stack trace is available. It should not contain passwords, session cookies, private encryption keys, full payment data, or unredacted personal records. When an identifier is needed for diagnosis, prefer a request ID, record ID, or redacted value.

logger.error("Failed to save profile for userId={}", userId, e);

At an application boundary, such as a command-line entry point, desktop UI controller, or web request handler, convert technical exceptions into appropriate responses. A command-line program may print a short message to standard error and return a nonzero exit code. A web application should return a suitable status code and a generic response instead of sending exception details to the client.

Design method contracts that make failure visible

Method names, return values, documentation, and exception types together form a contract. A method named findUser may reasonably return Optional<User> when “not found” is normal. A method named getUserOrThrow makes a different promise: it either returns a user or signals an exceptional absence.

Do not use null as a vague signal for every kind of failure. A caller cannot tell whether null means “not found,” “invalid input,” “network failure,” or “a bug occurred.” Use Optional selectively for expected absence, and use exceptions or result types when failures need explanation.

Assertions are not input validation

Java assertions are intended to verify internal assumptions during development and testing:

assert total >= 0 : "Total cannot be negative";

Assertions can be disabled at runtime, so they must not enforce security checks, user input rules, permissions, or essential business logic. Use ordinary conditional checks and appropriate exceptions for conditions that must always be enforced.

Test the unhappy paths

A method is not fully tested simply because it succeeds with ideal input. Test malformed data, missing files, unavailable dependencies, boundary values, and cleanup after failures. In JUnit, assertThrows makes an expected failure explicit:

@Test
void rejectsNegativeQuantity() {
    IllegalArgumentException exception = assertThrows(
        IllegalArgumentException.class,
        () -> order.setQuantity(-1)
    );

    assertEquals("Quantity must be positive", exception.getMessage());
}

Keep file and network tests controlled. Use temporary directories, test doubles, local services, or approved lab environments instead of relying on external systems. Test whether resources are closed and whether a failed update leaves data consistent. A small failure-path test often reveals missing validation or an overly broad catch block before it becomes a production incident.

A practical exception-handling workflow

1. Validate untrusted input at the boundary where it enters the program.
2. Identify whether a failure is expected, recoverable, or a programming defect.
3. Catch only exceptions the current layer can handle or meaningfully translate.
4. Preserve the original cause when wrapping an exception.
5. Close files, streams, and connections with try-with-resources.
6. Present safe messages to users and keep detailed diagnostics in protected logs.
7. Test failure cases with the same care given to successful behavior.

Before adding a catch block, state exactly what condition the program will be in after it runs. After a failed configuration load, for example, either defaults are fully applied and clearly reported, or startup stops before a partially configured service accepts work. That decision prevents the misleading state where an exception disappears but the application is no longer safe to trust.