Custom Exception.

Think of a custom exception as a bright warning label you add to your own code when Java's built-in errors are too vague. Interviewers love this topic because it shows whether you can turn a business rule into a clear, maintainable failure.

Question: What is a custom exception in Java, and when should I create one?

Answer: A custom exception is a class you write to represent a specific problem in your application, like InsufficientBalanceException or InvalidOrderStateException. In Java, it usually extends Exception for a checked exception or RuntimeException for an unchecked one. You create it when a built-in exception does not describe the real business problem clearly enough.

Interview-Ready Answer: I use a custom exception when I want a failure to mean something specific in my domain, not just a generic Java error. I usually extend Exception if the caller must handle it, or RuntimeException if it is a programming or validation error. I also add constructors for a message and cause, so I can keep the original root problem and make debugging easier.

What a custom exception really is

A custom exception is just a class whose job is to say, this exact thing went wrong. The value is not fancy syntax; the value is meaning. Instead of throwing a generic Exception, you give the caller a name that matches the business rule, so code becomes easier to read, test, and log.

How it works under the hood

1. You define a class that extends Exception or RuntimeException.
2. When a rule is broken, you create the object with new and immediately throw it.
3. Java stores the message and captures the stack trace, which is the path of method calls that led to the error.
4. If it is a checked exception, the compiler forces the method to declare throws or handle it with try/catch.
5. The caller can catch it, log it, translate it into another exception, or let it propagate upward.
6. Because the stack trace points to the throw site, you can usually find the bug faster than with a vague generic exception.

Checked vs unchecked custom exceptions

Choose the type based on who should deal with the problem. If the caller can reasonably recover, a checked exception is useful. If the issue is a programming mistake, bad input, or a rule violation that should fail fast, an unchecked exception is often cleaner.

When to use them

• Business rules: the error has domain meaning, like an order being shipped twice.
• API boundaries: the caller needs a clear signal instead of a generic failure.
• Translation: wrap a lower-level exception so higher layers see a cleaner message.
• Testing and logs: a specific type is easier to assert on and search for in production logs.

When not to use them

• Do not use exceptions for normal control flow in loops or simple branching.
• Do not create many nearly identical exception classes if one good type is enough.
• Do not hide the original cause; keep it with super(message, cause) when wrapping.

Performance and edge cases

Throwing an exception is much slower than a normal if check because the JVM has to allocate the object and capture a stack trace. In a web app, that stack trace can include tens of frames, so the cost grows with call depth. That is why exceptions belong on rare failure paths, not inside hot loops or tight data-processing code.

One practical detail: custom exceptions are objects, so they can carry fields, but keep them small and meaningful. If the exception may be serialized across a remote boundary, define a serialVersionUID to keep versions compatible. And when you translate an exception from a lower layer, always preserve the root cause so you do not lose the real bug.

Memory image: a custom exception is a labeled smoke alarm: the room is still on fire, but now you know exactly which room and why.

Real-world story

Imagine a checkout service in an e-commerce app. When a customer places an order, the service checks stock, payment status, and shipping rules. A custom exception like InsufficientStockException or PaymentDeclinedException makes the failure explicit, so the API can return a helpful message and the monitoring system can count the right kind of problem.

Now imagine a misunderstanding: a developer catches every failure and rethrows a generic RuntimeException. In production, the logs start showing the same vague message for stock shortages, card declines, and database timeouts. Users see a bland 500 Internal Server Error, support cannot tell what failed, and the retry system may keep retrying a payment that will never succeed. The symptom is a spike in failed checkouts, noisy logs with repeated generic stack traces, and a dashboard that cannot separate business failures from real system outages. A well-named custom exception prevents that confusion and makes the incident easier to diagnose.

Follow-up & Tricky Questions:

• When should I use a checked custom exception instead of an unchecked one? Use checked exceptions when the caller can realistically recover and you want the compiler to enforce handling. Use unchecked exceptions when the problem is usually a programming bug, invalid state, or input that should fail fast.
• Why not just throw Exception everywhere? Because a generic type hides the real meaning of the failure and makes catch blocks less precise. A specific exception improves readability, logging, and testing.
• How do I preserve the original cause? Add a constructor that accepts Throwable cause and pass it to super(message, cause). That keeps the root stack trace visible when you debug.
• Can a custom exception have fields? Yes, but keep them small and useful, such as an error code or an ID. Do not store large objects or business entities unless there is a very strong reason.
• Should custom exceptions be serializable? Java exceptions already implement Serializable, but if the type may cross JVM boundaries or be stored long-term, define serialVersionUID for compatibility.
• Is throw the same as throws? No. throw creates and sends one exception object, while throws declares that a method may pass an exception to its caller.
• Can I catch a custom exception and ignore it? Technically yes, but usually no. Swallowing it hides the failure and makes production bugs much harder to find.
• Does a custom exception automatically make code better? Not by itself. It helps only when the name, type, and handling strategy match a real domain problem.

Tricky / gotcha questions:

• If I extend RuntimeException, do I lose stack traces? No. You still get a stack trace when the exception is thrown; it is just unchecked, so the compiler does not force a catch or declaration.
• Should I make every validation error a custom exception? Usually no. For simple argument problems, IllegalArgumentException is often enough and keeps the API simpler.
• Can one method throw both checked and unchecked custom exceptions? Yes, but use that carefully. Mixed exception styles are fine if they communicate different kinds of failure clearly.

Common Mistakes:

• Using a generic exception type for everything — fix it by naming the real business failure so callers know what happened.
• Forgetting to keep the root cause — fix it by using constructors like (message, cause) when wrapping another exception.
• Using exceptions for normal logic — fix it by using if checks for expected branches and exceptions only for rare failure paths.
• Making every custom exception checked by default — fix it by choosing checked only when the caller can actually recover.

Memory Hook: A custom exception is a labeled smoke alarm: the alarm says something is wrong, and your label tells you exactly which room is burning.

Cheat Sheet:

• Custom exception = your own class for a specific failure.
• Extend Exception for checked, RuntimeException for unchecked.
• Use it when built-in exceptions are too vague for your domain.
• Add constructors for message and cause.
• Keep exceptions rare; do not use them as normal control flow.

Practice Tasks:

• Create a InvalidAgeException and throw it when age is below 18.
• Change the demo to extend RuntimeException and remove the throws clause.
• Add a second field, like an error code, and print it in the catch block.