throws Declaration Without Actual Throw

Yes, you can have a throws declaration without the body actually throwing that exception, at least for checked exceptions. The compiler treats the throws clause as the maximum set of checked exceptions the method is allowed to propagate — it's an upper bound, not a requirement that the body actually throw each one. So if I write a method that just adds two numbers but I declare throws I O exception on it, that compiles perfectly fine, even though there's no way an I O exception could ever come out of it. The interesting part is the consequence, which falls on the caller. Because the signature advertises that the method might throw I O exception, every caller is now forced to either catch it or declare throws themselves, even though it can never actually happen. So you end up with dead try-catch blocks that handle an impossible case, which is just noise that makes the code harder to read and leaks a misleading contract. So while it's legal, over-declaring is a bad habit. The rule I'd follow is to declare exactly the checked exceptions you genuinely propagate — no more, no less. There is one legitimate exception to that, which is interface or base-class methods. There it can make sense to declare a broader throws clause that implementations might need, even if a particular implementation doesn't throw it. A classic example is AutoCloseable's close method declaring throws Exception, so that any implementation is free to throw whatever it needs. But for ordinary concrete methods, keep the throws clause honest and tight.