Checked Exception Rules in Method Overriding

No, a subclass method that overrides a parent method cannot declare broader or new checked exceptions than the parent. What it can do is declare the same checked exceptions, or narrower ones — meaning subtypes of what the parent declared — or fewer of them, or even none at all. But it can never widen the set or introduce a brand-new checked exception that the parent didn't declare. The reason comes down to substitutability, the Liskov substitution idea. When some code holds a reference of the parent type and calls the method, it was compiled against the parent's signature, so it only prepared to handle the checked exceptions the parent declared. If a subclass were allowed to throw some new checked exception, that caller would suddenly be hit by an exception it never had any reason to handle, which would break the guarantee that a subclass can stand in safely for its parent. So the compiler enforces this. A concrete example: if the parent's read method declares throws I O exception, then an override can declare throws FileNotFoundException, because that's a subclass of I O exception, or it can declare nothing at all, but it cannot declare throws Exception, because Exception is broader than I O exception. The one thing this rule does not restrict is unchecked exceptions. An override is free to throw any RuntimeException it likes, because callers were never forced to handle those in the first place, so there's no contract to violate. And this same rule applies when you implement an interface method, not just when you extend a class.