Creating Custom Exceptions in Java
Fast recall
Quick revision
Core answer
RuntimeException for unchecked (no caller burden), Exception for checked (forced handling). Always provide both constructors: (String message) and (String message, Throwable cause) — never lose the original cause. Add context fields (orderId, userId) for diagnosability. Rule: checked when caller can meaningfully recover; unchecked for invariant violations and programming errors.Whether the candidate knows when to create custom exceptions vs reusing standard ones, how to choose between checked and unchecked, and what makes a custom exception useful beyond just having a custom name
Creating custom exceptions that add nothing — just a new class name with no extra fields or context. Using checked exceptions for everything when the caller has no reasonable recovery strategy. Forgetting to pass the original cause to the constructor, losing the root cause stack trace
Show a custom exception with domain-specific fields (error code, entity ID) that make debugging easier. Explain exception chaining with the cause parameter. Mention that most modern Java services use unchecked custom exceptions with structured error codes for REST API error mapping
Interview-ready guide
Interview answer
Custom exceptions are worth creating when they carry domain-specific context that standard exceptions can't — an order ID, an error code, a retry-after timestamp.
When to create vs reuse
- If it just extends
RuntimeExceptionwith a message string, useIllegalArgumentExceptionorIllegalStateExceptioninstead - Create a custom exception when you need structured data the error-handling layer can extract programmatically
- Don't create one class per error condition — group related failures under one exception with an enum error code field
Checked vs unchecked
- If the caller has a genuine recovery strategy (retry, fallback, user prompt) — checked exception makes sense
- If recovery isn't realistic — extend
RuntimeExceptionand let a global handler map it to an HTTP response - Most modern REST services use unchecked custom exceptions; the boundary handler translates them
The mistake everyone makes
- Forgetting the cause constructor:
super(message, cause)preserves the original stack trace - Wrapping a
SQLExceptionwithout passing the cause = the root error disappears completely - Always provide both
(String message)and(String message, Throwable cause)constructors
Constructor pattern:
- Always provide both
(String message)and(String message, Throwable cause)constructors
I recommend creating custom exceptions only when they carry domain-specific data — otherwise reuse IllegalArgumentException or IllegalStateException.
Creating Custom Exceptions in Java
Direct Answer
Extend RuntimeException for unchecked (no caller burden), Exception for checked (forced handling). Always provide both constructors: (String message) and (String message, Throwable cause) — never lose the original cause. Add context fields (orderId, userId) for diagnosability. Rule: checked when caller can meaningfully recover; unchecked for invariant violations and programming errors.
Common Mistakes & Pitfalls
Creating custom exceptions that add nothing — just a new class name with no extra fields or context. Using checked exceptions for everything when the caller has no reasonable recovery strategy. Forgetting to pass the original cause to the constructor, losing the root cause stack trace
Check your understanding
Answer these without looking back at the article.
- When should a custom exception extend RuntimeException vs Exception?
- Why is it critical to always pass the original cause to the super constructor?
- What context fields should a production exception carry and why do they matter in debugging?
- What is the difference between exception wrapping and exception translation?
- Why is catching a checked exception and rethrowing an unchecked one without the cause a bad practice?
Related interview prep categories
1Looking for a structured roadmap?
Every module on this page is also part of the full Java backend interview track.