Java · Intermediate level

Intermediate level · Module 3: Exceptions and File Input/Output in Java · Lesson 1 of 3

Handling Exceptions

Understand the exception hierarchy, the difference between checked and unchecked exceptions, and how to catch and rethrow responsibly.

In this lesson you will

  • Explain checked versus unchecked exceptions
  • Use try/catch/finally and decide where an exception should be handled

Key concepts

Throwable, Exception, RuntimeExceptionchecked exceptionstack tracefinally

The lesson

Exceptions report problems. Checked exceptions, such as IOException, represent problems outside the program's control that the compiler forces you to handle or declare with throws. Unchecked exceptions extend RuntimeException, such as NullPointerException, and usually signal programming mistakes that should be fixed rather than caught.

Catch an exception only where you can do something useful: retry, use a default, or show a helpful message. Otherwise let it travel up to a level that can. Never write an empty catch block — it hides the problem and makes bugs very hard to find.

Read a stack trace from the top: the first line names the exception and message, and the lines below show the methods that were running, with the most recent first. The first line that mentions your own code is usually where to look.

Step by step

  1. Trigger an ArithmeticException, a NullPointerException and a NumberFormatException on purpose.
  2. Read each stack trace and find the line in your code.
  3. Catch the NumberFormatException and ask for input again.
  4. Add a finally block and observe when it runs.
Troubleshooting tree

Which Java exception is this, and what should I do?

From the first line of a stack trace to the right response: fix the code, handle the input, or handle the environment.

Is it a NullPointerException, ArrayIndexOutOfBoundsException or ClassCastException?
  • Yes
    This is a programming error. Do not catch it — find the line in your code named in the stack trace and fix the logic (check for null, correct the index range, fix the types).
  • No
    Is it NumberFormatException, InputMismatchException or IllegalArgumentException caused by user input?
    • Yes
      The input was invalid. Validate it where it is read: catch the exception, show a clear message and ask again.
    • No
      Is it an IOException (for example NoSuchFileException) or SQLException?
      • Yes
        The environment failed — a missing file, a full disk, a database that is down. Handle it at a level that can respond: report it clearly, use a fallback or stop safely, and close resources with try-with-resources.
      • No
        Search the exception's name in the Java API documentation, reproduce it with the smallest possible program and ask for help with that example and the full stack trace.

Notes

Read the stack trace from the top: the first line names the exception and message; the first line mentioning your own package shows where to look.

Practice activity

Take a program that crashes on bad data and add exception handling so it reports the problem clearly and continues where that makes sense.

Expected result: Bad input produces a clear message and the program continues; programming errors still show a stack trace to fix.

Check your understanding

  1. Is IOException checked or unchecked?

    Show answer

    Checked — it must be caught or declared with throws.

  2. Why is an empty catch block dangerous?

    Show answer

    It hides the error, so the program continues in a wrong state without anyone knowing why.

Taught live by an instructor — online or in person. Free course lessons are for self-study and do not lead to a certificate — see registration options.