How does the throws clause interact with method overriding — what can an overriding method declare?

## Setup: what overriding is **Overriding** is when a subclass (or implementing class) provides its own version of a method that a superclass or interface already defines, with the same name and parameter types. At runtime, a call through a supertype reference dispatches to the subtype's version (dynamic dispatch). For this to be safe, the subtype's method must be **substitutable** for the supertype's — callers written against the supertype must not break. ## The throws rule for overrides An **overriding method may not broaden the checked-exception contract**. Concretely, every checked exception the override declares in its `throws` clause must be the same as, or a **subtype of**, some checked exception declared by the overridden method. The override **may**: - declare the **same** checked exceptions, - declare **narrower** ones (subtypes of the parent's), - declare **fewer** (a subset), - declare **none** at all. The override **may not**: - declare a checked exception **not covered** by the parent's clause (e.g. an unrelated checked type), - declare a **broader** checked exception (a supertype of what the parent declared, including `Exception` or `Throwable`). ## Why — substitutability Consider a caller holding a supertype reference: ```java Reader r = getReader(); // could be any subtype try { r.read(); // Reader.read() declares IOException } catch (IOException e) { ... } ``` The caller only prepared to handle `IOException` because that's all the *supertype* promised. If a subtype's override could declare `throws SQLException`, the caller would suddenly receive a checked exception it never planned for — defeating compile-time safety. So the language forbids widening the checked contract. Declaring **narrower or fewer** is fine: the caller's `catch (IOException e)` still covers a `FileNotFoundException`, and handling *fewer* exceptions never surprises anyone. ## Unchecked exceptions are unrestricted Because unchecked exceptions (`RuntimeException`, `Error` and subclasses) are never part of the enforced contract, an override can throw **any** of them regardless of the parent's clause. The rule constrains **checked** exceptions only. ## Worked examples Parent: ```java class Base { void op() throws IOException { } } ``` Valid overrides: ```java void op() throws IOException { } // same void op() throws FileNotFoundException { } // subtype of IOException void op() { } // none — allowed void op() throws IllegalStateException { } // unchecked — always allowed ``` Invalid overrides (compile errors): ```java void op() throws Exception { } // broader than IOException void op() throws SQLException { } // unrelated checked exception ``` ## Interfaces and multiple inheritance of type When a method implements/overrides declarations from multiple supertypes (e.g. several interfaces), the implementing method may only declare checked exceptions allowed by **all** of them — effectively the intersection of what each permits. If the interfaces declare disjoint checked exceptions, the implementer can declare none of the conflicting ones. ## Constructors are different Note the override rule is about methods. Constructors aren't overridden, but a subclass constructor's `throws` clause **must include** the checked exceptions thrown by the superclass constructor it implicitly/explicitly calls — a separate, opposite-feeling requirement. ## Deriving the answer The single principle to remember: *an override can only keep or shrink the checked-exception promise, never grow it* — because callers coded to the supertype's promise must never be ambushed. Unchecked exceptions sit outside the promise entirely.