throw vs throws in Java

They're only one letter apart but they do completely different jobs, and they live on opposite sides of the process. Throw, without an s, is an executable statement. It actually raises an exception at runtime. You write throw, then a new exception instance, and at that point control immediately jumps to the nearest matching catch block, or propagates up if there isn't one. So throw takes a single exception object and fires it. Throws, with an s, is a declaration that goes in the method signature. It doesn't raise anything by itself — it just tells the compiler and anyone calling the method that this method might propagate these checked exceptions, so the caller needs to be prepared to either catch them or declare them in turn. So throws takes a list of exception types, not an instance. A clean way to remember it: throw is what you do, throws is what you warn about. One important nuance is that throws is only required for checked exceptions. If your method can propagate an I O exception and you're not catching it, you must declare throws I O exception, or the code won't compile. But for unchecked exceptions — anything extending RuntimeException, like IllegalArgumentException or NullPointerException — you never need a throws clause, even though you can still throw them. So in a typical method you might use both: a throw statement in the body to raise an unchecked exception when an argument is invalid, and a throws clause in the signature to declare a checked exception that a library call might propagate. The mistake to avoid is thinking throws raises the exception or that throw declares it — they're strictly the runtime action versus the compile-time declaration.