Nearby lessons
59 of 125Java - Exceptions Overview
- What an exception is and why programs crash
- The try, catch, finally structure
- Checked vs unchecked exceptions (with the updated rule)
- throw vs throws
- Creating your own (custom) exceptions
- try-with-resources — the modern way
Exceptions Overview is a core concept of the Java language. This lesson explains What is an Exception?, Error vs Exception — Question and Answer and Pure Checked vs Partially Checked Exceptions with complete, runnable code examples, clear step-by-step explanations, and common mistakes to avoid with exam-style MCQs at the end.
What is an Exception?
An exception is an event that happens during the running of a program and stops the normal flow. For example, dividing a number by zero, opening a file that does not exist, or accessing index 10 of a 5-element array.
Without handling, an exception makes the program crash suddenly and all work is lost. Exception handling is the art of catching these problems and giving the user a friendly message instead of a crash.
Error vs Exception — Question and Answer
First, understand that a problem in a program is either an Error or an Exception:
| Point | Error | Exception |
|---|---|---|
| What it is | A serious system-level problem | A problem in the program's logic/flow |
| Examples | OutOfMemoryError, StackOverflowError | ArithmeticException, IOException |
| Can we catch it? | Usually not (not meant to be caught) | Yes — that is what exception handling is for |
| Who fixes it | Fix the design/code, or give more memory | Handle with try-catch |
Errors are further divided by when they happen:
| Type of error | When it happens | Example |
|---|---|---|
| Compile-time error | While compiling | nit i = 10; (lexical), missing ; (syntax), using undeclared variable (semantic) |
| Runtime error | While running | Dividing by zero, array index out of bounds |
Compile-time errors come in three kinds: lexical (wrong keywords/spelling), syntax (wrong structure), and semantic (meaning errors like wrong types). Runtime errors are mostly exceptions.
Pure Checked vs Partially Checked Exceptions
Checked exceptions are divided into two further types — a classic exam question:
| Type | Meaning | Examples |
|---|---|---|
| Pure checked | Its sub classes are ALL checked exceptions | IOException (all its children are checked) |
| Partially checked | Has at least one unchecked exception as a sub class | Exception, Throwable (they include RuntimeException) |
Simple memory: IOException is pure checked; Exception and Throwable are partially checked because they also cover RuntimeException.
The Exception Hierarchy (Quick Map)
Checked vs Unchecked Exceptions
Exceptions are divided into two big families:
| Point | Checked exceptions | Unchecked exceptions |
|---|---|---|
| Checked by compiler? | Yes — compiler forces you to handle them | No — you may handle but are not forced |
| Parent class | Exception (sub classes) | RuntimeException (sub classes) |
| Example | IOException, SQLException | ArithmeticException, NullPointerException |
| Cause | External things: file missing, network down | Programming mistakes |
| Must handle? | Yes, with try-catch or throws | Optional (but good practice) |
Best Practices — Trainer's Checklist
- Catch exceptions where you can do something meaningful — do not swallow them with an empty catch block.
- Never catch a NullPointerException to hide a bug — find why the value is null instead.
- Always close resources (use try-with-resources).
- Log the exception details (stack trace) instead of just printing a message in production.
- Throw specific exceptions (NumberFormatException) rather than a general Exception.
- finally is the right place for cleanup that must run whether an error happened or not.
- Exception = a run-time problem that stops the program; handling prevents the crash.
- try keeps risky code, catch handles the problem, finally always runs.
- Checked exceptions must be handled; unchecked (RuntimeException) are optional to handle.
- throw throws an exception; throws warns that a method may throw one.
- Custom exceptions extend Exception or RuntimeException for business rules.
- try-with-resources (Java 7+) closes files/connections automatically.
- Errors (like OutOfMemoryError) are system problems — not meant to be caught.