throw vs throws.

Hook: Interviewers love this one because a single word decides whether you are doing the throwing or only declaring that a method might throw.

Question: What is the difference between throw and throws in Java?

Answer: throw is used inside a method to actually send one exception object to the JVM. throws is used in a method or constructor signature to say, “this code may pass this checked exception to the caller.” In short: throw performs the action; throws announces the contract.

Interview-Ready Answer: I use throw when I want to create and raise a specific exception right now, like throw new IllegalArgumentException(...). I use throws in the method signature when I want to declare that a checked exception may escape to the caller, such as throws IOException. So the easy memory is: throw is the act, and throws is the promise.

Big picture

Detailed Explanation: Think of throw as the moment the problem is raised, and throws as the method saying, “I might let this problem bubble up.” A throw happens at runtime; a throws clause is mainly a compile-time promise.

How it works under the hood

1. You create an exception object, usually with new.
2. throw immediately hands that object to the JVM and stops the current method’s normal flow.
3. The JVM starts stack unwinding, which means it walks back through caller methods one frame at a time until it finds a matching catch.
4. If a handler is found, control jumps there; if not, the thread ends and Java prints a stack trace.
5. throws does not throw anything by itself. It only appears in a method or constructor signature.
6. For checked exceptions (exceptions the compiler enforces), callers must either catch them or declare them again with throws.

What to use when

• Use throw when the current method detects bad input, illegal state, or a condition it cannot continue with.
• Use throws when a method cannot fully handle a checked problem such as file access, network access, or a database read.
• Use unchecked exceptions like IllegalArgumentException for programmer mistakes or invalid state that the caller should not be forced to handle.

Comparison

Performance and limits

Normal execution with throws has essentially no runtime cost. Throwing is much more expensive than an if branch: object creation is roughly O(1), but stack unwinding is O(d), where d is the number of stack frames between the throw site and the handler. In real code, that can feel like microseconds to low milliseconds, depending on stack depth and how much stack trace data is collected. That is why exceptions are for unusual situations, not everyday control flow.

Important edge cases

• throw must be followed by a Throwable object, not a primitive or a string.
• throws can be used on methods and constructors, not on fields or local variables.
• You can list multiple exception types in throws, separated by commas.
• Overriding methods may narrow checked exceptions, but they cannot widen them.
• throw null; compiles, but it ends in a NullPointerException at runtime.

Memory guide: throw is the alarm button you press; throws is the sign that says the alarm might ring.

Real-world story

In an e-commerce checkout service, one method validates user input and another calls a tax API. The input validator uses throw to reject an empty postal code immediately, because the request is already invalid. The tax client uses throws IOException because it cannot fix a network failure itself; it must let the caller decide whether to retry, fail fast, or fall back.

What goes wrong when someone mixes them up? A developer may swallow a checked exception in a catch-all block, or forget to declare it and then wrap everything in a vague runtime exception. In production, users start seeing generic checkout failures, logs lose the original cause, and retry traffic spikes because a temporary network problem is being treated like a business-rule bug.

The symptom pattern is very recognizable: sudden 500 errors, stack traces that end too early, and support tickets saying orders cannot complete even though cart validation looks fine. The fix is simple but important: use throw to signal the exact bad condition, and use throws to keep the checked error visible until the right layer handles it.

Follow-up & Tricky Questions:

• Can throws be used with runtime exceptions? Yes, you can declare them, but the compiler does not require it. It is usually optional and mainly used for documentation or API design clarity.
• What is the difference between checked and unchecked exceptions? Checked exceptions must be caught or declared, while unchecked exceptions extend RuntimeException and do not have to be declared.
• Can a method declare more than one exception in throws? Yes. You can write multiple types separated by commas, but inside the method body each throw still throws only one exception object at a time.
• Can an overriding method change the throws clause? Yes, but only by narrowing it or removing checked exceptions. It cannot add broader checked exceptions than the parent method.
• What happens if nobody catches the exception? The JVM keeps unwinding the stack until the thread ends. You will usually see a stack trace, and in a server app the request fails.
• Is throw a method? No. It is a Java statement, so it lives inside method or constructor bodies.
• Can throw accept an exception class name? No. It must be an exception object, such as new IOException(...).
• Can throws appear inside a method body? No. It belongs in the signature only, right after the parameter list.

Common Mistakes:

• Mixing up action and declaration. Correction: throw is used inside the method body; throws is used in the method or constructor signature.
• Trying to throw a class or a primitive. Correction: you must throw an object that extends Throwable, such as new Exception(...).
• Using checked exceptions for routine validation. Correction: use unchecked exceptions for programmer errors and checked exceptions when the caller can realistically recover.
• Swallowing the exception and losing the cause. Correction: either handle it meaningfully or rethrow with enough context to debug the root problem.

Memory Hook: throw is the fire alarm button; throws is the sign on the wall that says the alarm may ring.

Cheat Sheet:

• throw = actually raise one exception object.
• throws = declare possible checked exceptions.
• throw goes in the body; throws goes in the signature.
• Checked exceptions must be caught or declared; unchecked exceptions do not have to be.
• Throwing is expensive compared with a normal branch, so do not use exceptions for everyday logic.

Practice Tasks:

• Change the example so that registerUser also rejects ages above 120 with throw.
• Add a new checked exception for blank names, then make a second method declare it with throws.
• Replace the custom exception with IOException-style thinking: write a method that declares a checked exception and another that handles it one layer up.