Exceptions and Assertions

In Java, an exception is an event that disrupts the normal flow of a program's instructions. Think of the Java Virtual Machine (JVM) as a factory floor manager who follows each line of your code step by step. Normally, the manager executes doThis(), then doThat(), then doTheOther(). But if doThis() tries to open a file that does not exist, the manager cannot just shrug and move on — the instruction is impossible to complete. Instead, the manager creates a special object called an exception (like a red alert token) and 'throws' it into the execution environment. If your code does not have a mechanism to 'catch' that token, the program crashes.

The core tools for handling exceptions are try, catch, and finally blocks. You wrap risky code inside a try block. For example:

try {
    int result = 10 / 0;  // This will cause an ArithmeticException
} catch (ArithmeticException e) {
    System.out.println("Cannot divide by zero!");
}

If an exception occurs inside the try block, the JVM immediately jumps to the matching catch block. The catch block is like your pre-planned recovery room for that specific type of red alert. A try can have multiple catch blocks to handle different exception types. Since Java 7, you can use a multi-catch clause: catch (IOException | SQLException e) to handle multiple exception types in one block if their handling logic is identical.

There is also the finally block. A finally block always executes, whether an exception was thrown or not. It is like the clean-up crew that locks the doors after the concert ends, even if a fire alarm forced everyone out early. You use finally to release resources, like closing a file or a database connection.

Then there is the try-with-resources statement, introduced in Java 7 and enhanced in Java 9. This is a specialised try block that automatically closes resources that implement the AutoCloseable interface. You declare the resources in parentheses after try. For example:

try (FileReader fr = new FileReader("data.txt");
     BufferedReader br = new BufferedReader(fr)) {
    // read file content
} catch (IOException e) {
    // handle errors
}

The try-with-resources block calls the close() method on each resource automatically at the end, even if an exception occurs. This replaces the old, error-prone pattern of manually closing resources in a finally block. It is cleaner and prevents resource leaks.

Now, assertions are a different tool. An assertion is a statement that you use to verify that a condition you believe to be true is actually true. You use it with the assert keyword: assert age >= 0 : "Age must be non-negative";. If age is -5, the assertion throws an AssertionError. Assertions are disabled by default at runtime. You enable them with a command-line flag (-ea). They are meant for development and testing, not for production. You should never rely on assertions for argument validation in public methods; that is what IllegalArgumentException (a standard exception) is for. Assertions check your program's internal assumptions — like ensuring a switch statement's default branch is never reached, or that a variable has been initialised before use.

An IT professional writing a banking application for an online payment system uses exceptions constantly. Consider a function that transfers money from one account to another. The normal flow is: check the sender has enough balance, debit the sender, credit the recipient, and log the transaction. But reality is messy.

Step one: the system tries to connect to the database to read the sender's balance. The database server might be down. This throws an SQLException. The developer wraps the database connection code in a try block. The catch block logs the error and sends a 'temporary outage' message to the customer, rather than crashing the entire ATM network.

Step two: the debit operation might fail because of a unique constraint violation (e.g. a duplicate transaction ID). The developer catches a DataIntegrityViolationException and retries with a new transaction ID.

Step three: after debiting the sender, what if the credit to the recipient fails? This is a critical issue — the sender lost money but the recipient did not receive it. The developer must handle this with a transaction rollback. This is often done with the try-with-resources pattern on a database connection, ensuring the transaction is rolled back in the catch or finally block. The finally block is essential here to close the database connection cleanly, even if an error occurred.

Assertions are used differently. A senior developer might write a utility method that calculates the interest rate based on account type. The method has a switch block for account types: SAVINGS, CHECKING, and INVESTMENT. The developer adds a default case not to handle a valid type, but to catch a programming mistake:

switch (accountType) {
    case SAVINGS: return 0.02;
    case CHECKING: return 0.01;
    case INVESTMENT: return 0.05;
    default: assert false : "Unknown account type: " + accountType;
}

If a new account type is added later but the switch is not updated, the assertion fires during testing, alerting the team immediately.

In practice, an IT professional writes unit tests that enable assertions. They run the code with the -ea flag in their local development environment and on the continuous integration server. They do not ship the code with assertions enabled in production because assertions can be turned off (and usually are) for performance reasons. They rely on standard exceptions and logging for production issues.

The workflow for a developer handling exceptions involves: