Exception Handling
Custom Exceptions
Design custom checked and unchecked exception classes, declare constructors, and handle chaining causes.
Interview: Evaluates custom exception class design, extending Exception vs. RuntimeException, and writing constructors that support exception chaining.
Declaring Custom Exceptions allows you to expose domain-specific error states. When creating custom exceptions, you should extend the appropriate base exception and implement standard constructors that support exception chaining.
Domain Modeling
Custom exceptions model domain-specific error conditions (e.g. OrderNotFoundException) instead of using generic exceptions.
Standard Constructors
Should implement the four standard constructors to support passing messages, causes (chaining), or both.
Base Selection
Extend Exception for checked exceptions. Extend RuntimeException for unchecked exceptions.
Writing the Standard Exception Constructors
To fully support standard Java patterns, a custom exception should implement:
- No-Argument Constructor:
public MyException() { super(); } - Message Constructor:
public MyException(String message) { super(message); } - Cause Constructor (for Chaining):
public MyException(Throwable cause) { super(cause); } - Message & Cause Constructor:
public MyException(String message, Throwable cause) { super(message, cause); }
Common Pitfalls
- Omitting the Cause Constructor: Creating custom exceptions that only accept a message, which prevents exception chaining and discards the root cause stack trace.
- Over-creating Custom Exceptions: Creating a new custom class for every single error scenario instead of reusing standard Java exceptions (like
IllegalArgumentException).
Best Practices
- Suffix with Exception: Always end custom exception class names with the suffix
Exception(e.g.PaymentException). - Prefer Unchecked: Extend
RuntimeExceptionfor custom exceptions unless callers must recover programmatically.
Interview-Relevant Information
Q1: How do you create a custom unchecked exception in Java?
Answer: Define a class that extends java.lang.RuntimeException and implement the standard constructors that pass parameters to the superclass.
Q2: Why should custom exceptions implement a constructor that accepts a Throwable cause?
Answer: To support exception chaining. This constructor allows wrapping lower-level exceptions inside your domain exception while preserving the original stack trace for debugging.
Quick Checklist
Can you write a custom exception class extending RuntimeException, declare the four standard constructors, and explain how to chain exceptions? If yes, you understand custom exceptions.
Use Cases
Modeling business rule violations inside core domain service packages.
Creating custom API error response wrappers for serialization frameworks.
Common Mistakes
Extending Exception when RuntimeException is more appropriate, forcing boilerplate try-catch logic onto callers.
Forgetting to declare serialVersionUID in custom exception classes that may undergo serialization.