Exception Rules in Java

The exception rules in Java decide what a method may declare in its throws clause once a child class shows up. Learn why overloads have no rules, what a child method may declare, and why unchecked types walk free.

1. Introduction

You write a subclass, add throws Exception to an overridden method, and the compiler refuses. Nothing looks wrong, and yet the build fails.

That wall you just hit has a name. The exception rules in Java govern what a method may declare in its throws clause. They kick in with overloads and with child classes.

The good news arrives early. Overloaded methods have no rules at all, so half this topic disappears in a single section.

Overriding is the half that matters. A child method may promise the same failures as its parent, or fewer, but never more.

This is part 5, the final part of our five-part series. Part 3 covered throw and throws, and part 4 covered custom and chained exceptions.

1.1 What This Article Covers

We start with the reason behind the rules, then work through every legal and illegal combination. Here is the plan:

• Why a child method cannot widen its parent’s throws clause
• Exception rules for overloaded methods, which turn out to be none
• The three things a child method may safely declare
• The two things that stop the build, with real compiler messages
• Why unchecked exceptions ignore all of this
• Every combination collected into one lookup table
• Interfaces, static method hiding, and constructors
• Common mistakes and interview questions

You need throws from part 3 and a working idea of inheritance. Everything else we build here.

2. The Idea Behind Every Rule

2.1 The Caller Sees the Parent Type

Rules learnt by heart work until you forget one. The reason behind them sticks for good, so let us start there.

Look at this line of code and ask what the compiler knows:

Report report = new PdfReport();   // reference type Report, object type PdfReport
report.export();

The compiler sees a Report reference and nothing more. Which object arrives at runtime depends on the code path, and it could be any subclass ever written.

So the compiler checks the throws clause of Report.export. That clause tells it which catch blocks you need.

2.2 A Promise Nobody May Break

Think of the parent method as a contract. It promises callers that it fails in these ways, and in no others.

Now picture a child that declares a brand new checked type. Your catch block would miss it, and the compiler could never warn you.

Java closes that hole at the source. A child may keep the promise or make a smaller one, and the compiler rejects anything bigger.

• Fewer exceptions than the parent keeps every existing caller valid.
• A subclass of a declared exception still matches the parent’s catch block.
• More exceptions would break callers who compiled fine yesterday.
• The rule protects callers, not the subclass author.

2.3 Checked Exceptions Only

One boundary matters before we go further. Every rule in this article applies to checked exceptions and nothing else.

Unchecked types stay out of the catch-or-declare rule, so widening them costs nothing. Part 1 of this series drew that line between the two families.

Keep this split in mind and half the muddle goes away.

3. Rules for Overloaded Methods

3.1 Overloads Are Separate Methods

Here is the whole section in one line. Overloads have no exception rules at all.

Why so simple? Because overloads only share a name. Different parameters make them genuinely different methods, and the compiler picks one at the call site.

Your caller therefore knows exactly which overload it invoked. Nothing can surprise it, so Java needs no rule here.

3.2 Three Overloads, Three throws Clauses

This class overloads save three times. One throws a checked exception, one throws a different checked exception, and one declares nothing.

package com.javahandson;

import java.io.IOException;

public class OverloadRules {

    static void save(String text) throws IOException {
        System.out.println("Saved text: " + text);
    }

    static void save(int id) throws IllegalAccessException {
        System.out.println("Saved id: " + id);
    }

    static void save(double amount) {                    // no throws clause at all
        System.out.println("Saved amount: " + amount);
    }

    public static void main(String[] args) throws IOException, IllegalAccessException {
        save("invoice");
        save(77);
        save(9.99);
    }
}
// Output:
// Saved text: invoice
// Saved id: 77
// Saved amount: 9.99

Three throws clauses in one class, with no link between them. IOException and IllegalAccessException meet only at Exception itself.

Look at main for the practical effect. It declares both checked types, because it calls both overloads.

Swap any of those for unchecked types and nothing changes. Mixing checked and unchecked across overloads works too.

3.3 The throws Clause Cannot Overload

One trap hides here, and interviewers love it. A throws clause is not part of the method signature.

static void save(String text) throws IOException { }
static void save(String text) throws SQLException { }
// error: method save(String) is already defined in class OverloadRules

Both methods take one String, so Java sees one method declared twice. Different exceptions change nothing.

The same applies to return types. Only the name and the parameter list distinguish one overload from another.

4. Rules for Overridden Methods

4.1 What a Child May Declare

Overriding is where the real rules live. A child method redefines a parent method, so callers cannot tell which version runs.

Three moves stay legal for checked exceptions:

• Declare the same exception type the parent declares.
• Pick a subclass of it, such as FileNotFoundException under IOException.
• List fewer types, right down to none at all.

Two moves stop the build. Declaring a supertype fails, and declaring an unrelated checked type fails too.

Notice the pattern. Everything the child declares must fit underneath something the parent already promised.

4.2 The Same Exception

Start with the obvious case. Repeating the parent’s exception always compiles.

package com.javahandson;

import java.io.IOException;

class Report {
    void export() throws IOException {
        System.out.println("Report exported");
    }
}

class PdfReport extends Report {
    @Override
    void export() throws IOException {          // identical clause, always legal
        System.out.println("PDF exported");
    }
}

public class SameException {
    public static void main(String[] args) throws IOException {
        Report report = new PdfReport();
        report.export();
    }
}
// Output: PDF exported

Main declares IOException because Report.export declares it. Whether a PdfReport or a plain Report turns up makes no difference to the compiler.

4.3 A Narrower Exception

Now let the child promise something smaller. FileNotFoundException extends IOException, so it fits underneath.

import java.io.FileNotFoundException;
import java.io.IOException;

class Report {
    void export() throws IOException {
        System.out.println("Report exported");
    }
}

class PdfReport extends Report {
    @Override
    void export() throws FileNotFoundException {     // narrower, perfectly legal
        System.out.println("PDF exported");
    }
}
// compiles cleanly

Any caller catching IOException still catches a FileNotFoundException, because catch matches subclasses. Nobody’s code breaks.

You may also list more than one type. Each must fit under a parent type. So throws FileNotFoundException, EOFException works fine here, since both extend IOException.

4.4 No Exception at All

A child can drop the throws clause completely. This surprises beginners, and it follows straight from the contract idea.

class Report {
    void export() throws IOException {
        System.out.println("Report exported");
    }
}

class PdfReport extends Report {
    @Override
    void export() {                    // declares nothing, still legal
        System.out.println("PDF exported");
    }
}

public class NoException {
    public static void main(String[] args) throws IOException {
        Report report = new PdfReport();
        report.export();               // main still needs IOException here

        PdfReport pdf = new PdfReport();
        pdf.export();                  // no handling needed with this reference type
    }
}
// Output:
// PDF exported
// PDF exported

Read those last two calls carefully, because they show the whole idea in action. The reference type decides what the compiler demands.

Through a Report reference, IOException remains on the table. Through a PdfReport reference, the compiler sees a method that promises nothing.

5. What Breaks the Rules

5.1 A Broader Exception

Widening is the classic failure. Exception sits above IOException, so the child promises more than the parent did.

class Report {
    void export() throws IOException {
    }
}

class PdfReport extends Report {
    @Override
    void export() throws Exception {         // too broad
    }
}
// error: export() in PdfReport cannot override export() in Report
//   overridden method does not throw Exception

That second line of the error says everything. Nothing in the parent covers Exception, so the compiler stops right there.

Picture the caller once more. It wrote catch (IOException e) and would now face an Exception nobody handles.

5.2 An Unrelated Checked Exception

Broader is not the only problem. A checked type from a completely different branch fails just as hard.

class PdfReport extends Report {
    @Override
    void export() throws SQLException {      // unrelated to IOException
    }
}
// error: export() in PdfReport cannot override export() in Report
//   overridden method does not throw SQLException

SQLException is neither broader nor narrower here. It has no place under IOException, and that alone rules it out.

So forget the words broader and narrower for a moment. The real test asks whether each declared type sits under something the parent promised.

5.3 When the Parent Declares Nothing

Here is the strictest case of all, and it catches people out constantly.

class Report {
    void export() {                       // no throws clause
    }
}

class PdfReport extends Report {
    @Override
    void export() throws IOException {    // no room for any checked exception
    }
}
// error: export() in PdfReport cannot override export() in Report
//   overridden method does not throw IOException

An empty throws clause leaves the child zero space. No checked exception can fit under a promise that lists nothing.

This bites hard when you implement an interface such as Runnable. Its run method declares nothing, so your implementation cannot let a checked exception escape.

What do you do then? Wrap it in an unchecked exception, exactly as part 4 showed with the (String, Throwable) constructor.

6. Unchecked Exceptions Go Free

6.1 No Restriction Whatsoever

Everything above concerned checked exceptions. Unchecked types walk straight past all of it.

package com.javahandson;

class Report {
    void export() throws ArithmeticException {          // unchecked
        System.out.println("Report exported");
    }
}

class PdfReport extends Report {
    @Override
    void export() throws RuntimeException {             // broader, and still fine
        throw new IllegalStateException("Template missing");
    }
}

public class UncheckedRules {
    public static void main(String[] args) {            // no throws, no try-catch
        Report report = new PdfReport();
        report.export();
    }
}
// Output:
// Exception in thread "main" java.lang.IllegalStateException: Template missing
//     at com.javahandson.PdfReport.export(UncheckedRules.java:12)
//     at com.javahandson.UncheckedRules.main(UncheckedRules.java:18)

RuntimeException sits above ArithmeticException, so this widens the clause. The compiler waves it through anyway.

Try any mix you like with unchecked types. Broad, narrow, or a class the parent never named, and it all compiles.

6.2 Why the Rule Skips Them

The reason follows from part 1. Nobody has to catch an unchecked exception, so no caller can break when a new one appears.

The rule exists to protect callers who wrote catch blocks under compiler orders. Unchecked exceptions never carried that obligation.

Errors work the same way. OutOfMemoryError and friends stay outside the rules for exactly the same reason.

6.3 Declaring Versus Actually Throwing

One point ties this whole article together. It splits people who know the topic from people who learnt it by rote.

The rules govern what a method declares. They say nothing about what it throws at runtime.

class PdfReport extends Report {
    @Override
    void export() {                                  // declares nothing at all
        throw new IllegalStateException("boom");     // yet it throws happily
    }
}

That method declares no exception and still ends the program. Nothing in the language stops a method from throwing unchecked types.

• The compiler checks throws clauses, never method bodies.
• Any method may throw an unchecked exception without declaring it.
• Checked exceptions inside the body still obey catch-or-declare.
• Runtime behaviour and compile-time rules answer different questions.

7. All the Rules in One Table

Every case for a child method fits into one lookup table. The parent method here declares whatever the first column says.

One sentence covers the entire table. Each checked type in the child must be the same as, or a subclass of, some type the parent declared.

8. Overloading vs Overriding

Both words start with the same six letters, and beginners mix them up under interview pressure. Here they are side by side.

Remember the one line that matters. Overloading gives you freedom, while overriding hands you a contract to honour.

9. Special Cases Worth Knowing

9.1 Interface Methods

Implementing an interface method follows identical rules. The interface declares the contract, and your class must stay inside it.

interface Storage {
    void write(String data) throws IOException;
}

class MemoryStorage implements Storage {
    @Override
    public void write(String data) {         // narrowing to nothing, legal
        System.out.println("Wrote " + data);
    }
}

This pattern shows up all over real code. An in-memory class cannot fail with an IOException, so it declares none.

9.2 Implementing Two Interfaces

Now a trickier case. One class implements two interfaces that declare the same method with different checked exceptions.

interface FileSource {
    void load() throws IOException;
}

interface DatabaseSource {
    void load() throws SQLException;
}

class HybridSource implements FileSource, DatabaseSource {
    @Override
    public void load() {          // must satisfy both, so no checked exception fits
        System.out.println("Loaded");
    }
}

Your method has to honour both contracts at once. IOException breaks the database contract, and SQLException breaks the file one.

Only the overlap survives, and these two share nothing. So the class declares no checked type at all.

9.3 Static Methods and Hiding

A static method in a child class does not override the parent version. It hides it, which is a different mechanism.

class Report {
    static void init() throws IOException {
    }
}

class PdfReport extends Report {
    static void init() throws Exception {     // hiding, and the same limit applies
    }
}
// error: init() in PdfReport cannot hide init() in Report
//   overridden method does not throw Exception

The mechanism changed, and the limit did not. Java applies the same throws rule to hiding as it does to overriding.

Two more cases need no rule at all. A private or final method cannot be overridden, so nothing constrains it.

9.4 Constructors Play by Other Rules

Constructors are never inherited, so they are never overridden either. That frees them from everything above.

class Report {
    Report() throws IOException {
    }
}

class PdfReport extends Report {
    PdfReport() throws IOException, SQLException {   // extra exception, and it compiles
        super();
    }
}

Notice the direction here. A child constructor must declare the checked exceptions of the super() call it makes, and it may add more of its own.

That is the exact opposite of the rule above. Constructors widen freely, while child methods must not.

9.5 Lambdas Follow the Same Rules

A lambda is just a method body for one interface method. So the throws clause of that interface still applies.

// Runnable.run declares nothing, so this will not compile
Runnable task = () -> Files.readString(Path.of("config.txt"));
// error: unreported exception IOException; must be caught or declared to be thrown

// Callable.call declares Exception, so the same body is fine here
Callable<String> job = () -> Files.readString(Path.of("config.txt"));

Same body, two results. Runnable promises no checked exception, while Callable promises Exception.

This trips up a lot of stream code too. The lambda you pass to map or forEach cannot let a checked exception out, so you catch it and wrap it inside the lambda.

10. Common Mistakes and Pitfalls

10.1 Declaring throws Exception in the Parent

Some coders write throws Exception on a base method so subclasses never hit the rule. It works, and it wrecks all the rest.

// Poor: every caller now handles a type that means nothing
abstract class Task {
    abstract void run() throws Exception;
}

// Better: name what this family of tasks can actually fail with
abstract class Task {
    abstract void run() throws TaskFailedException;
}

The broad version pushes catch (Exception e) into every caller. Part 3 explained why that hides real failures.

10.2 Confusing Declaring With Throwing

Plenty of people believe a child method cannot throw anything new at runtime. Only the declaration faces restrictions.

A child that declares nothing can still throw ten different unchecked exceptions. The compiler never inspects the body for those.

10.3 Expecting the Child Clause to Matter

Assigning a child object to a parent reference does not shrink your obligations. The reference type wins every time.

Report report = new PdfReport();   // PdfReport.export declares nothing
report.export();                   // you still handle IOException here

PdfReport pdf = new PdfReport();
pdf.export();                      // now the compiler asks for nothing

Same object, same method, two different demands from the compiler. Only the declared type of the variable changed.

10.4 Fighting the Rule Instead of Wrapping

You override a method that declares nothing, and your body needs to call something throwing IOException. Beginners then edit the parent class.

@Override
public void run() {
    try {
        Files.readString(Path.of("config.txt"));
    } catch (IOException e) {
        throw new ConfigLoadException("Cannot read config.txt", e);   // wrap it
    }
}

Catch the checked exception and wrap it in an unchecked one, keeping the original as the cause. Part 4 covered that pattern in detail.

10.5 Skipping the Override Annotation

Leave out @Override and a typo in the method name creates a brand new method instead. No rule applies, no error appears, and your code silently calls the parent version.

Add the annotation to every method you intend to override. The compiler then checks your intent, exception rules included.

11. A Practical Walkthrough

11.1 The Task

Let us build something that shows why the rule earns its keep. We need a validator family with three implementations.

The base class declares throws IOException, since a validator might read a rules file. One child narrows that to FileNotFoundException, and another drops it entirely.

Then we loop over all three through a single parent-typed array. One catch block should cover every one of them.

11.2 The Code

package com.javahandson;

import java.io.FileNotFoundException;
import java.io.IOException;

class Validator {

    // the contract: validation may fail with an IOException
    void validate(String input) throws IOException {
        System.out.println("Base check passed for [" + input + "]");
    }
}

class StrictValidator extends Validator {

    @Override
    void validate(String input) throws FileNotFoundException {   // narrower
        if (input.isBlank()) {
            throw new FileNotFoundException("No rules file for a blank input");
        }
        System.out.println("Strict check passed for [" + input + "]");
    }
}

class LenientValidator extends Validator {

    @Override
    void validate(String input) {                                // nothing at all
        System.out.println("Lenient check passed for [" + input + "]");
    }
}

public class ValidatorApp {

    public static void main(String[] args) {
        Validator[] validators = {
                new Validator(),
                new StrictValidator(),
                new LenientValidator()
        };

        for (Validator validator : validators) {
            try {
                validator.validate("");
            } catch (IOException e) {          // one catch covers the whole family
                System.out.println(validator.getClass().getSimpleName()
                        + " failed: " + e.getMessage());
            }
        }
    }
}
// Output:
// Base check passed for []
// StrictValidator failed: No rules file for a blank input
// Lenient check passed for []

11.3 Reading the Output

Walk the loop three times. The base validator prints its line and returns normally.

StrictValidator throws a FileNotFoundException on the blank input. Our catch block asks for IOException, and FileNotFoundException extends it, so the match works.

LenientValidator declares nothing and simply prints. The catch block sits there unused, which costs nothing.

Now spot the payoff hiding in that catch line:

• One catch block handles every present and future subclass.
• Adding a fourth validator tomorrow cannot break this loop.
• The compiler guarantees no child sneaks in a new checked type.
• Narrowing stays invisible to the caller, exactly as it should.

Try breaking it yourself. Add throws Exception to any child and the build fails before the loop ever runs.

12. Interview Questions

13. Conclusion

Let us wrap up what we covered. Overloads carry no exception rules. Different parameter lists make them separate methods.

Overriding is where the restriction lives. Each checked exception in the child must be the same as, or a subclass of, something the parent already declared.

Three moves stay legal: the same type, a narrower type, or nothing at all. Widening fails, an unrelated checked type fails, and a parent with an empty clause leaves the child no room.

Unchecked exceptions ignore every one of these rules. Remember too that the rules police the throws clause, never the method body.

Behind all of it sits one idea. A caller holding a parent reference wrote its catch blocks from the parent contract, and no subclass may quietly break that.

This article closes our five-part exception series. You now know what exceptions are, how to catch them, and how to throw them. You can write and chain your own, and you know the rules a child class adds on top.

Further Reading

• Introduction to Exception Handling in Java
• try, catch and finally Blocks in Java
• Throwing Exceptions in Java
• Custom and Chained Exceptions in Java
• Polymorphism in Java
• Understanding Inheritance in Java