All 15 Exceptions questions
More in Exceptions
What is a common anti-pattern with catching exceptions too broadly (catch (Exception e) or worse, catch (Throwable t)), and why is it generally discouraged? What is the finally block's execution guarantee, and what are the specific edge cases where a finally block might NOT execute? What is the multi-catch syntax (catch (IOException | SQLException e)) introduced in Java 7, and what restriction applies to the exception types combined in a single multi-catch block? What is the difference between Error and Exception in Java's Throwable hierarchy, and why should application code generally avoid catching Error subclasses like OutOfMemoryError or StackOverflowError? What is the purpose of the addSuppressed() mechanism and getSuppressed() method on Throwable, and in what specific scenario does the JVM automatically populate suppressed exceptions? How does exception chaining (via the cause mechanism, initCause() or a constructor accepting a Throwable) preserve the original root-cause exception when wrapping and rethrowing a different exception type, and why does this matter for debugging? How would you design a custom exception hierarchy for an application, deciding when to create new exception classes versus reusing existing ones, and what fields/context should a well-designed custom exception carry? How does exception handling interact with performance, particularly regarding the cost of filling in a stack trace, and how would you optimize exception usage in a performance-critical hot path? How would you implement a custom checked exception that requires additional context to be attached as the exception propagates up multiple layers of a call stack, without losing information at each layer? How does exception handling interact with generics and type erasure, specifically regarding why you cannot catch a generic type parameter as an exception type (catch (T e))?
Advertisement
Back to results for “Exception Handling”
Java › Exceptions

How do you create and throw a custom exception class, and what constructors should a well-designed custom exception typically provide?

Intermediate

Answer

A custom exception extends either Exception (checked) or RuntimeException (unchecked) as appropriate, and by convention should provide at least the standard four constructors mirroring Throwable's own (no-arg, message-only, message-plus-cause, and cause-only), ensuring the custom exception integrates smoothly with common exception-handling patterns (like wrapping-and-rethrowing with a cause) that calling code and libraries typically expect to be available on any well-behaved exception class.
public class InsufficientFundsException extends RuntimeException {
    public InsufficientFundsException() { super(); }
    public InsufficientFundsException(String message) { super(message); }
    public InsufficientFundsException(String message, Throwable cause) { super(message, cause); }
    public InsufficientFundsException(Throwable cause) { super(cause); }
}

throw new InsufficientFundsException("Account balance too low for withdrawal of $500");
Real-world example A banking application's InsufficientFundsException provides all four standard constructors, letting it be thrown with just a descriptive message in most cases, but also usable with a wrapped cause when the insufficient-funds determination itself resulted from a downstream service call failure.

Common follow-ups: Why is it considered good practice to provide all four standard constructors even if only one is currently used?;What naming convention (ending in 'Exception') helps make custom exception classes immediately recognizable in a codebase?

OOP & Classes;Error Handling
All 15 Exceptions questions