Module 9: Exceptions, Validation, and Debugging
Custom Exceptions for Business Rules
Create business-friendly exception types that explain what went wrong without hiding the real cause.
Author
Java Learner Editorial Team
Reviewer
Technical review by Java Learner
Last reviewed
2026-04-17
Java version
Java 25 LTS
Learning goals
- Create exception types that reflect your domain
- Choose checked vs unchecked intentionally
- Add context without burying the real cause
Custom exceptions make business rules clearer: InsufficientFundsException tells a stronger story than a generic RuntimeException.
Checked or unchecked depends on caller responsibility: If callers can recover, checked can make sense. If it signals invalid program flow or invalid requests, unchecked is often simpler.
Always preserve the original cause when wrapping: That keeps stack traces honest and debugging possible.
Good naming matters: Exception names should reveal what failed, not just that “something went wrong.”
Runnable examples
A focused custom exception
class InvalidScoreException extends IllegalArgumentException {
public InvalidScoreException(String message) {
super(message);
}
}
throw new InvalidScoreException("Score must be between 0 and 100.");Expected output
Throws a domain-specific unchecked exception with a clear message.
Mini exercise
Create a custom exception for invalid booking dates or invalid bank transfers in a small class you already understand.
Summary
- Custom exception names should match real business failures.
- Use checked vs unchecked based on caller responsibility.
- Preserve the original cause when wrapping exceptions.
Next step
The last two lessons turn exception theory into debugging practice with stack traces, logging, and a small failure-handling project.
Sources used