System Design (LLD)Exception Hierarchy Design

Exception Hierarchy Design

LevelIntermediate

Duration60 mins

TopicException Hierarchy Design

4 / 4

Naming Conventions

The Power of Precise Names

Names are interfaces. When a developer sees throw new UserSuspendedDueToFraudException(userId) in a stack trace, they immediately understand what happened without reading any documentation. When an operator sees error code PAYMENT.CAPTURE.GATEWAY_TIMEOUT in a dashboard, they know exactly which system is failing.

Poor naming forces investigation that good naming eliminates. This page establishes conventions for naming exception classes, error codes, and messages that make your error handling self-documenting, consistent, and operationally transparent.

What You Will Learn

By completing this page, you will master: (1) exception class naming patterns that reveal intent, (2) error code design for operational visibility, (3) message formatting for debugging efficiency, (4) consistency rules that scale across large codebases, and (5) practical naming examples across multiple scenarios.

Exception Class Naming Principles

Exception class names should be immediately comprehensible in a stack trace. A developer debugging at 3 AM should understand what went wrong from the class name alone, without needing to open source files.

Core Naming Principles

•Describe What Happened, Not What To Do — InsufficientFundsException, not AddMoreFundsException
•Use Domain Language — OrderNotFoundException not EntityNotFoundInDatabaseException
•Be Specific — EmailAlreadyRegisteredException not DuplicateException
•Include Context When Valuable — PaymentGatewayTimeoutException not just TimeoutException
•End With 'Exception' or 'Error' — Follow your language's convention (Java: Exception, JS/TS: Error)

Poor Names

•GenericException — Tells nothing
•Error1, Error2 — Meaningless
•MyAppException — Which failure?
•BadDataException — What's bad about it?
•ProcessingException — What processing?
•InvalidException — Invalid what?
•FailedException — Everything failed!
•UserException — User did what?

Good Names

•UserNotFoundException — Clear: user wasn't found
•PaymentDeclinedException — Clear: payment rejected
•InsufficientInventoryException — Clear: not enough stock
•EmailFormatInvalidException — Clear: email format wrong
•OrderAlreadyShippedException — Clear: can't modify shipped order
•TokenExpiredException — Clear: auth token is stale
•RateLimitExceededException — Clear: too many requests
•ConcurrentModificationException — Clear: race condition

The Stack Trace Test

Imagine seeing only the exception class name in a stack trace with no other context. Can you tell what happened? If not, the name needs work. Good names make stack traces readable narratives: 'at OrderService.submit() → OrderValidationException → PaymentService.charge() → InsufficientFundsException'.

Naming Patterns by Category

Different exception categories follow different naming patterns. These patterns make exceptions predictable and discoverable across your codebase.

Not Found Exceptions

Pattern: {Entity}NotFoundException or {Entity}NotFoundError

Not Found Naming Pattern
Java
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
// Pattern: {Entity}NotFoundException
public class UserNotFoundException extends EntityNotFoundException { }
public class OrderNotFoundException extends EntityNotFoundException { }
public class ProductNotFoundException extends EntityNotFoundException { }
public class InvoiceNotFoundException extends EntityNotFoundException { }
 
// If lookup is by something other than ID, include it:
public class UserByEmailNotFoundException extends UserNotFoundException { }
public class OrderByReferenceNotFoundException extends OrderNotFoundException { }
 
// Base class for the pattern:
public abstract class EntityNotFoundException extends BusinessException {
    protected EntityNotFoundException(String message, String entityType, String id) {
        super(message, entityType.toUpperCase() + ".NOT_FOUND",
              Map.of("entityType", entityType, "entityId", id));
    }
    
    @Override
    public int suggestedHttpStatus() {
        return 404;
    }
}

Conflict/Already Exists Exceptions

Pattern: {Entity}AlreadyExistsException or {Entity}Already{State}Exception

Conflict Naming Pattern
Java
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
// Pattern: {Entity}AlreadyExistsException
public class UserAlreadyExistsException extends ConflictException { }
public class EmailAlreadyRegisteredException extends ConflictException { }
public class ProductSkuAlreadyExistsException extends ConflictException { }
 
// Pattern: {Entity}Already{State}Exception
public class OrderAlreadySubmittedException extends ConflictException { }
public class OrderAlreadyCancelledException extends ConflictException { }
public class PaymentAlreadyCaptured extends ConflictException { }
public class ShipmentAlreadyDispatchedException extends ConflictException { }
 
// Pattern: Concurrent modification
public class OrderConcurrentModificationException extends ConflictException { }
public class OptimisticLockException extends ConflictException { }
 
// Base class:
public abstract class ConflictException extends BusinessException {
    protected ConflictException(String message, String errorCode) {
        super(message, errorCode);
    }
    
    @Override
    public int suggestedHttpStatus() {
        return 409;  // Conflict
    }
}

Validation Exceptions

Pattern: {Field/Entity}Validation{Issue}Exception or Invalid{Thing}Exception

Validation Naming Pattern
Java
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
// Pattern: Invalid{Thing}Exception (simple cases)
public class InvalidEmailFormatException extends ValidationException { }
public class InvalidPhoneNumberException extends ValidationException { }
public class InvalidDateRangeException extends ValidationException { }
public class InvalidCredentialsException extends AuthenticationException { }
 
// Pattern: {Field}{Issue}Exception (specific field issues)
public class PasswordTooWeakException extends ValidationException { }
public class UsernameTooShortException extends ValidationException { }
public class AmountNegativeException extends ValidationException { }
 
// Pattern: {Entity}ValidationException (aggregate of field errors)
public class OrderValidationException extends ValidationException { }
public class UserProfileValidationException extends ValidationException { }
 
// Pattern: Missing required data
public class MissingShippingAddressException extends ValidationException { }
public class MissingPaymentMethodException extends ValidationException { }
public class RequiredFieldMissingException extends ValidationException { }

Business Rule Violations

Pattern: {Rule}ViolationException or {Action}NotAllowedException

Business Rule Naming Pattern
Java
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
// Pattern: Insufficient/Exceeded resource
public class InsufficientFundsException extends BusinessException { }
public class InsufficientInventoryException extends BusinessException { }
public class QuotaExceededException extends BusinessException { }
public class RateLimitExceededException extends BusinessException { }
public class StorageLimitExceededException extends BusinessException { }
 
// Pattern: {Action}Not{Condition}Exception (can't do X because of Y)
public class OrderNotCancellableException extends BusinessException { }
public class UserNotActivatedException extends BusinessException { }
public class SubscriptionNotActiveException extends BusinessException { }
public class ItemNotRefundableException extends BusinessException { }
 
// Pattern: {State/Condition}Exception (entity in wrong state)
public class AccountSuspendedException extends BusinessException { }
public class ProductDiscontinuedException extends BusinessException { }
public class PromotionExpiredException extends BusinessException { }
 
// Pattern: {Domain}{Rule}ViolationException (formal invariant)
public class OrderMinimumNotMetException extends BusinessException { }
public class MaximumQuantityExceededException extends BusinessException { }
public class BusinessDayRequiredException extends BusinessException { }

Technical/Infrastructure Exceptions

Pattern: {System}{Issue}Exception or {Operation}FailedException

Technical Naming Pattern
Java
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
// Pattern: {System}{Issue}Exception
public class DatabaseConnectionException extends TechnicalException { }
public class DatabaseTimeoutException extends TechnicalException { }
public class CacheUnavailableException extends TechnicalException { }
public class MessageBrokerException extends TechnicalException { }
 
// Pattern: {ExternalService}Exception
public class PaymentGatewayException extends TechnicalException { }
public class EmailServiceException extends TechnicalException { }
public class StorageServiceException extends TechnicalException { }
public class SearchIndexException extends TechnicalException { }
 
// Pattern: {ExternalService}{Specific}Exception
public class PaymentGatewayTimeoutException extends PaymentGatewayException { }
public class PaymentGatewayUnavailableException extends PaymentGatewayException { }
public class StripeApiException extends PaymentGatewayException { }
 
// Pattern: {Operation}FailedException (when operation name is clearer)
public class SerializationFailedException extends TechnicalException { }
public class EncryptionFailedException extends TechnicalException { }
public class FileUploadFailedException extends TechnicalException { }

Error Code Design

Error codes are machine-readable identifiers that support monitoring, alerting, documentation, and client-side handling. Good error codes are hierarchical, consistent, and stable across releases.

Error Code Structure

Recommended Pattern: {DOMAIN}.{CATEGORY}.{SPECIFIC}

Error Code Components
Component	Purpose	Examples
Domain	Which business domain or system	`ORDER`, `USER`, `PAYMENT`, `AUTH`
Category	Type of failure within domain	`VALIDATION`, `NOT_FOUND`, `CONFLICT`, `GATEWAY`
Specific	Exact failure condition	`AMOUNT_NEGATIVE`, `EMAIL_TAKEN`, `TIMEOUT`

Error Code Examples

Examples

# Error Code Hierarchy Examples
 
ORDER.NOT_FOUND                      # Order doesn't exist
ORDER.VALIDATION.ITEMS_EMPTY         # Order has no items
ORDER.VALIDATION.AMOUNT_NEGATIVE     # Invalid amount
ORDER.CONFLICT.ALREADY_SUBMITTED     # Can't modify submitted order
ORDER.CONFLICT.ALREADY_CANCELLED     # Already cancelled
ORDER.INVENTORY.INSUFFICIENT         # Not enough stock
ORDER.SHIPPING.ADDRESS_REQUIRED      # Missing address
 
USER.NOT_FOUND                       # User doesn't exist
USER.VALIDATION.EMAIL_INVALID        # Bad email format
USER.VALIDATION.PASSWORD_WEAK        # Password doesn't meet requirements
USER.CONFLICT.EMAIL_TAKEN            # Email already registered
USER.STATE.SUSPENDED                 # Account suspended
USER.STATE.NOT_VERIFIED              # Email not verified
 
PAYMENT.DECLINED                     # Generic decline
PAYMENT.DECLINED.INSUFFICIENT_FUNDS  # Specific: not enough money
PAYMENT.DECLINED.CARD_EXPIRED        # Specific: card expired
PAYMENT.DECLINED.FRAUD_SUSPECTED     # Specific: fraud check failed
PAYMENT.GATEWAY.TIMEOUT              # Gateway didn't respond
PAYMENT.GATEWAY.UNAVAILABLE          # Gateway is down
PAYMENT.CAPTURE.ALREADY_CAPTURED     # Can't capture twice
 
AUTH.INVALID_CREDENTIALS             # Wrong username/password
AUTH.TOKEN.EXPIRED                   # Token past expiry
AUTH.TOKEN.INVALID                   # Token malformed/tampered
AUTH.PERMISSION.DENIED               # Not authorized
AUTH.RATE_LIMITED                    # Too many attempts
 
INFRA.DATABASE.CONNECTION_FAILED     # Can't connect to DB
INFRA.DATABASE.TIMEOUT               # Query took too long
INFRA.CACHE.UNAVAILABLE              # Cache is down
INFRA.MESSAGING.PUBLISH_FAILED       # Message publish failed

Error Code Best Practices

•Use SCREAMING_SNAKE_CASE — Distinguishes from regular text; standard for constants
•Keep domains stable — Don't rename domains; clients may depend on them
•Document publicly-exposed codes — API contracts should list possible error codes
•Use prefixes for filtering — ORDER.* matches all order errors in monitoring
•Avoid numbers — ERROR_42 means nothing; ORDER.NOT_FOUND is self-documenting
•Be consistent — If you use .NOT_FOUND for one entity, use it for all

Error Code Implementation
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
/**
 * Centralized error code constants.
 * Provides type safety, discoverability, and documentation.
 */
public final class ErrorCodes {
    
    private ErrorCodes() {} // Utility class
    
    // ==========================================
    // ORDER DOMAIN
    // ==========================================
    public static final class Order {
        private static final String PREFIX = "ORDER.";
        
        public static final String NOT_FOUND = PREFIX + "NOT_FOUND";
        
        public static final class Validation {
            private static final String PREFIX = Order.PREFIX + "VALIDATION.";
            
            public static final String ITEMS_EMPTY = PREFIX + "ITEMS_EMPTY";
            public static final String AMOUNT_NEGATIVE = PREFIX + "AMOUNT_NEGATIVE";
            public static final String QUANTITY_INVALID = PREFIX + "QUANTITY_INVALID";
        }
        
        public static final class Conflict {
            private static final String PREFIX = Order.PREFIX + "CONFLICT.";
            
            public static final String ALREADY_SUBMITTED = PREFIX + "ALREADY_SUBMITTED";
            public static final String ALREADY_CANCELLED = PREFIX + "ALREADY_CANCELLED";
            public static final String CONCURRENT_MODIFICATION = PREFIX + "CONCURRENT_MODIFICATION";
        }
        
        public static final class Inventory {
            private static final String PREFIX = Order.PREFIX + "INVENTORY.";
            
            public static final String INSUFFICIENT = PREFIX + "INSUFFICIENT";
            public static final String RESERVED = PREFIX + "RESERVED";
        }
    }
    
    // ==========================================
    // USER DOMAIN
    // ==========================================
    public static final class User {
        private static final String PREFIX = "USER.";
        
        public static final String NOT_FOUND = PREFIX + "NOT_FOUND";
        
        public static final class Validation {
            private static final String PREFIX = User.PREFIX + "VALIDATION.";
            
            public static final String EMAIL_INVALID = PREFIX + "EMAIL_INVALID";
            public static final String PASSWORD_WEAK = PREFIX + "PASSWORD_WEAK";
        }
        
        public static final class Conflict {
            private static final String PREFIX = User.PREFIX + "CONFLICT.";
            
            public static final String EMAIL_TAKEN = PREFIX + "EMAIL_TAKEN";
            public static final String USERNAME_TAKEN = PREFIX + "USERNAME_TAKEN";
        }
    }
    
    // Usage in exceptions:
    // throw new OrderNotFoundException(orderId, ErrorCodes.Order.NOT_FOUND);
    // throw new ValidationException(errors, ErrorCodes.Order.Validation.ITEMS_EMPTY);
}

Message Formatting Guidelines

Exception messages appear in logs, monitoring dashboards, and sometimes error responses. They should be consistently formatted, information-rich, and safe to display.

Message Construction Patterns

Build messages from exception data rather than accepting raw strings. This ensures consistency and prevents information omission.

Message Construction Patterns
Java
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
public class OrderNotFoundException extends OrderException {
    
    // ❌ BAD: Accept raw message (inconsistent, error-prone)
    public OrderNotFoundException(String message) {
        super(message);  // Caller might forget order ID!
    }
    
    // ✅ GOOD: Build message from structured data
    public OrderNotFoundException(OrderId orderId) {
        super(
            buildMessage(orderId),  // Consistent message
            ErrorCodes.Order.NOT_FOUND,
            orderId
        );
    }
    
    // ✅ GOOD: Optional lookup context for richer messages
    public OrderNotFoundException(OrderId orderId, LookupContext context) {
        super(
            buildMessageWithContext(orderId, context),
            ErrorCodes.Order.NOT_FOUND,
            orderId
        );
    }
    
    private static String buildMessage(OrderId orderId) {
        return format("Order not found: %s", orderId.value());
    }
    
    private static String buildMessageWithContext(OrderId orderId, LookupContext ctx) {
        return format("Order %s not found (looked up by: %s, user: %s)",
            orderId.value(),
            ctx.lookupMethod(),
            ctx.requestingUserId()
        );
    }
}
 
 
// =====================================================
// MESSAGE TEMPLATES FOR CONSISTENCY
// =====================================================
 
public final class MessageTemplates {
    
    // Entity not found messages
    public static String entityNotFound(String entityType, String id) {
        return format("%s not found: %s", entityType, id);
    }
    
    // Conflict messages
    public static String alreadyExists(String entityType, String field, String value) {
        return format("%s with %s '%s' already exists", entityType, field, value);
    }
    
    public static String alreadyInState(String entityType, String id, String state) {
        return format("%s %s is already %s", entityType, id, state);
    }
    
    // Validation messages
    public static String fieldInvalid(String field, String reason) {
        return format("Invalid value for '%s': %s", field, reason);
    }
    
    public static String fieldRequired(String field) {
        return format("Field '%s' is required", field);
    }
    
    // Insufficient resource messages
    public static String insufficientResource(String resource, Object required, Object available) {
        return format("Insufficient %s: required %s, available %s", 
            resource, required, available);
    }
    
    // Technical failure messages
    public static String serviceUnavailable(String serviceName) {
        return format("Service unavailable: %s", serviceName);
    }
    
    public static String operationTimeout(String operation, Duration timeout) {
        return format("Operation '%s' timed out after %s", operation, timeout);
    }
}
 
// Usage:
throw new UserNotFoundException(userId);  // Uses: "User not found: {id}"
throw new InsufficientFundsException(
    MessageTemplates.insufficientResource("funds", required, available),
    paymentId
);

Message Formatting Rules

•Include identifiers — Always include entity IDs, correlation IDs, or other lookup keys
•State facts, not actions — 'Order not found' not 'Please check order ID'
•Use consistent structure — '{Entity} not found: {id}' across all not-found exceptions
•No sensitive data — Never include passwords, tokens, or full credit card numbers
•Be concise — Log context separately; messages should be scannable
•Consider log parsing — Consistent structure enables log analysis and alerting

Sensitive Data in Messages

Exception messages often end up in logs, error tracking systems, and sometimes client responses. NEVER include: passwords, API keys, tokens, full credit card numbers, SSNs, or other PII. When including identifiers, consider whether they're sensitive in your context.

Naming Across Languages and Teams

In polyglot environments or large organizations, exception naming should be consistent across languages and services. Error codes especially must match, as they're used in API contracts and monitoring systems.

Language-Specific Conventions
Language	Class Suffix	Case Style	Example
Java	`Exception`	PascalCase	`UserNotFoundException`
C#	`Exception`	PascalCase	`UserNotFoundException`
Python	`Error`	PascalCase	`UserNotFoundError`
TypeScript	`Error`	PascalCase	`UserNotFoundError`
Go	N/A (errors are values)	camelCase	`errUserNotFound`
Rust	`Error` (in enum)	PascalCase	`Error::UserNotFound`

Cross-Language Consistency Example
1
2
3
4
5
6
7
8
// Java: UserNotFoundException with error code USER.NOT_FOUND
public class UserNotFoundException extends EntityNotFoundException {
    public UserNotFoundException(UserId userId) {
        super("User not found: " + userId.value(), 
              "USER.NOT_FOUND",  // Same error code across all services
              userId.value());
    }
}

Cross-Team Standards Document

For organizations with multiple services, publish a naming standards document:

Exception Naming Standards (Example)
Markdown
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
# Exception Naming Standards
 
## Error Code Format
All error codes follow: `{DOMAIN}.{CATEGORY}.{SPECIFIC}`
 
### Reserved Domains
- ORDER - Order processing
- USER - User management  
- PAYMENT - Payment processing
- AUTH - Authentication/authorization
- INFRA - Infrastructure
 
### Standard Categories
- NOT_FOUND - Entity doesn't exist (→ HTTP 404)
- VALIDATION - Input validation failed (→ HTTP 400)
- CONFLICT - State conflict (→ HTTP 409)
- STATE - Invalid state transition (→ HTTP 422)
- GATEWAY - External service issue (→ HTTP 503)
 
### Class Naming
- Java/C#: `{Entity}{Issue}Exception`
- Python/TS: `{Entity}{Issue}Error`
- Follow domain's existing patterns
 
### Message Format
- Format: "{Entity} {action/state}: {details}"
- Include relevant IDs
- No sensitive data
- State facts, not actions
 
### Examples
| Error Code | Java Class | Message |
|------------|------------|---------|
| USER.NOT_FOUND | UserNotFoundException | User not found: usr_123 |
| ORDER.CONFLICT.ALREADY_CANCELLED | OrderAlreadyCancelledException | Order ord_456 was already cancelled |
| PAYMENT.DECLINED.INSUFFICIENT_FUNDS | InsufficientFundsException | Payment declined: insufficient funds for $50.00 |

Common Naming Mistakes

Even experienced developers make naming mistakes. Here are the most common anti-patterns and their fixes:

Common Naming Mistakes and Fixes
Mistake	Why It's Bad	Better Alternative
`MyAppException`	Every exception is "your app's"; no information	`OrderValidationException`
`Error1`, `Error2`	Completely meaningless	`UserNotFoundException`, `PaymentDeclinedException`
`GenericException`	Admits it's generic—so why use it?	Use specific subtypes
`DatabaseException` for all DB issues	Lumps together distinct failures	`ConnectionTimeoutException`, `ConstraintViolationException`
`BadRequestException`	HTTP-centric; domain layer shouldn't know HTTP	`ValidationException`, `MissingFieldException`
`check if user exist exception`	Not a valid class name format	`UserExistenceCheckException` or better: `UserNotFoundException`
Error code: `42`	Numbers without context are useless	`USER.NOT_FOUND`
Error code: `userNotFound`	Inconsistent casing, no hierarchy	`USER.NOT_FOUND`
Message: `Error`	Says literally nothing	`User not found: usr_123`
Message: `Something went wrong`	Completely unhelpful for debugging	`Payment capture failed: gateway timeout after 30s`

Naming Anti-Pattern Examples
Java
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
// ❌ ANTI-PATTERN: Vague generic names
public class DataException extends Exception { }
public class ServiceException extends Exception { }
public class ProcessException extends Exception { }
// What data? Which service? What process?
 
// ❌ ANTI-PATTERN: Implementation details in names
public class DatabaseSQLIntegrityConstraintViolationException { }
public class HttpClientConnectionPoolTimeoutException { }
// Too long; exposes implementation
 
// ❌ ANTI-PATTERN: Action-oriented names
public class RetryLaterException extends Exception { }
public class ContactSupportException extends Exception { }
public class FixYourInputException extends Exception { }
// Names should describe WHAT happened, not WHAT TO DO
 
// ❌ ANTI-PATTERN: Negative-only names
public class NotOkException extends Exception { }
public class InvalidException extends Exception { }
public class FailureException extends Exception { }
// What exactly isn't ok/valid/failed?
 
// ❌ ANTI-PATTERN: Redundant naming
public class ExceptionException extends Exception { }  // Seriously?
public class ErrorExceptionError extends Exception { } // Worse
public class UserExceptionUserFailed extends Exception { } // Confused
 
 
// ✅ GOOD: Clear, specific, domain-oriented names
public class UserNotFoundException extends EntityNotFoundException { }
public class PaymentGatewayTimeoutException extends TechnicalException { }
public class InsufficientInventoryException extends OrderException { }
public class EmailAlreadyRegisteredException extends ConflictException { }
public class PasswordStrengthInsufficientException extends ValidationException { }

The New Team Member Test

Would a developer joining your team tomorrow understand what the exception means just from its name? If you need to explain it, consider renaming. Good names are self-documenting; great names tell a story.

Summary: Naming Conventions

Naming is a critical design activity. Well-named exceptions make systems self-documenting, debugging efficient, and operations transparent. Invest time in naming conventions early—they compound across the lifetime of your codebase.

Key Takeaways

•Class names describe what happened — InsufficientFundsException not AddFundsException
•Follow category patterns — {Entity}NotFoundException, {Entity}AlreadyExistsException, etc.
•Error codes are hierarchical — DOMAIN.CATEGORY.SPECIFIC (e.g., ORDER.INVENTORY.INSUFFICIENT)
•Error codes are stable — They're API contracts; don't change without versioning
•Messages are constructed, not accepted — Build from structured data for consistency
•Messages include identifiers — Always include order ID, user ID, etc. for tracing
•Maintain cross-team consistency — Same error codes across services enable unified monitoring

Module Complete!

You've now learned the complete discipline of exception hierarchy design:

Base Exception Classes — The foundation of your hierarchy, integrating with language conventions
Custom Exception Classes — Domain-specific types with rich, actionable information
Exception Categorization — Organizing exceptions for handling, monitoring, and documentation
Naming Conventions — Making exceptions self-documenting through precise, consistent naming

With these skills, you can design exception systems that make error handling clear, debugging efficient, and operations transparent.

Module Complete

You have completed Module 2: Exception Hierarchy Design. You now possess the design knowledge to create world-class exception architectures that serve developers, operators, and end users effectively. Apply these principles consistently across your codebases for robust, maintainable error handling.

4 / 4

Loading learning content...

System Design (LLD)Exception Hierarchy Design

Exception Hierarchy Design

LevelIntermediate

Duration60 mins

TopicException Hierarchy Design

4 / 4

Naming Conventions

The Power of Precise Names

What You Will Learn

Exception Class Naming Principles

Core Naming Principles

•Describe What Happened, Not What To Do — InsufficientFundsException, not AddMoreFundsException
•Use Domain Language — OrderNotFoundException not EntityNotFoundInDatabaseException
•Be Specific — EmailAlreadyRegisteredException not DuplicateException
•Include Context When Valuable — PaymentGatewayTimeoutException not just TimeoutException
•End With 'Exception' or 'Error' — Follow your language's convention (Java: Exception, JS/TS: Error)

Poor Names

•GenericException — Tells nothing
•Error1, Error2 — Meaningless
•MyAppException — Which failure?
•BadDataException — What's bad about it?
•ProcessingException — What processing?
•InvalidException — Invalid what?
•FailedException — Everything failed!
•UserException — User did what?

Good Names

•UserNotFoundException — Clear: user wasn't found
•PaymentDeclinedException — Clear: payment rejected
•InsufficientInventoryException — Clear: not enough stock
•EmailFormatInvalidException — Clear: email format wrong
•OrderAlreadyShippedException — Clear: can't modify shipped order
•TokenExpiredException — Clear: auth token is stale
•RateLimitExceededException — Clear: too many requests
•ConcurrentModificationException — Clear: race condition

The Stack Trace Test

Naming Patterns by Category

Different exception categories follow different naming patterns. These patterns make exceptions predictable and discoverable across your codebase.

Not Found Exceptions

Pattern: {Entity}NotFoundException or {Entity}NotFoundError

Not Found Naming Pattern
Java
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
// Pattern: {Entity}NotFoundException
public class UserNotFoundException extends EntityNotFoundException { }
public class OrderNotFoundException extends EntityNotFoundException { }
public class ProductNotFoundException extends EntityNotFoundException { }
public class InvoiceNotFoundException extends EntityNotFoundException { }
 
// If lookup is by something other than ID, include it:
public class UserByEmailNotFoundException extends UserNotFoundException { }
public class OrderByReferenceNotFoundException extends OrderNotFoundException { }
 
// Base class for the pattern:
public abstract class EntityNotFoundException extends BusinessException {
    protected EntityNotFoundException(String message, String entityType, String id) {
        super(message, entityType.toUpperCase() + ".NOT_FOUND",
              Map.of("entityType", entityType, "entityId", id));
    }
    
    @Override
    public int suggestedHttpStatus() {
        return 404;
    }
}

Conflict/Already Exists Exceptions

Pattern: {Entity}AlreadyExistsException or {Entity}Already{State}Exception

Conflict Naming Pattern
Java
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
// Pattern: {Entity}AlreadyExistsException
public class UserAlreadyExistsException extends ConflictException { }
public class EmailAlreadyRegisteredException extends ConflictException { }
public class ProductSkuAlreadyExistsException extends ConflictException { }
 
// Pattern: {Entity}Already{State}Exception
public class OrderAlreadySubmittedException extends ConflictException { }
public class OrderAlreadyCancelledException extends ConflictException { }
public class PaymentAlreadyCaptured extends ConflictException { }
public class ShipmentAlreadyDispatchedException extends ConflictException { }
 
// Pattern: Concurrent modification
public class OrderConcurrentModificationException extends ConflictException { }
public class OptimisticLockException extends ConflictException { }
 
// Base class:
public abstract class ConflictException extends BusinessException {
    protected ConflictException(String message, String errorCode) {
        super(message, errorCode);
    }
    
    @Override
    public int suggestedHttpStatus() {
        return 409;  // Conflict
    }
}

Validation Exceptions

Pattern: {Field/Entity}Validation{Issue}Exception or Invalid{Thing}Exception

Validation Naming Pattern
Java
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
// Pattern: Invalid{Thing}Exception (simple cases)
public class InvalidEmailFormatException extends ValidationException { }
public class InvalidPhoneNumberException extends ValidationException { }
public class InvalidDateRangeException extends ValidationException { }
public class InvalidCredentialsException extends AuthenticationException { }
 
// Pattern: {Field}{Issue}Exception (specific field issues)
public class PasswordTooWeakException extends ValidationException { }
public class UsernameTooShortException extends ValidationException { }
public class AmountNegativeException extends ValidationException { }
 
// Pattern: {Entity}ValidationException (aggregate of field errors)
public class OrderValidationException extends ValidationException { }
public class UserProfileValidationException extends ValidationException { }
 
// Pattern: Missing required data
public class MissingShippingAddressException extends ValidationException { }
public class MissingPaymentMethodException extends ValidationException { }
public class RequiredFieldMissingException extends ValidationException { }

Business Rule Violations

Pattern: {Rule}ViolationException or {Action}NotAllowedException

Business Rule Naming Pattern
Java
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
// Pattern: Insufficient/Exceeded resource
public class InsufficientFundsException extends BusinessException { }
public class InsufficientInventoryException extends BusinessException { }
public class QuotaExceededException extends BusinessException { }
public class RateLimitExceededException extends BusinessException { }
public class StorageLimitExceededException extends BusinessException { }
 
// Pattern: {Action}Not{Condition}Exception (can't do X because of Y)
public class OrderNotCancellableException extends BusinessException { }
public class UserNotActivatedException extends BusinessException { }
public class SubscriptionNotActiveException extends BusinessException { }
public class ItemNotRefundableException extends BusinessException { }
 
// Pattern: {State/Condition}Exception (entity in wrong state)
public class AccountSuspendedException extends BusinessException { }
public class ProductDiscontinuedException extends BusinessException { }
public class PromotionExpiredException extends BusinessException { }
 
// Pattern: {Domain}{Rule}ViolationException (formal invariant)
public class OrderMinimumNotMetException extends BusinessException { }
public class MaximumQuantityExceededException extends BusinessException { }
public class BusinessDayRequiredException extends BusinessException { }

Technical/Infrastructure Exceptions

Pattern: {System}{Issue}Exception or {Operation}FailedException

Technical Naming Pattern
Java
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
// Pattern: {System}{Issue}Exception
public class DatabaseConnectionException extends TechnicalException { }
public class DatabaseTimeoutException extends TechnicalException { }
public class CacheUnavailableException extends TechnicalException { }
public class MessageBrokerException extends TechnicalException { }
 
// Pattern: {ExternalService}Exception
public class PaymentGatewayException extends TechnicalException { }
public class EmailServiceException extends TechnicalException { }
public class StorageServiceException extends TechnicalException { }
public class SearchIndexException extends TechnicalException { }
 
// Pattern: {ExternalService}{Specific}Exception
public class PaymentGatewayTimeoutException extends PaymentGatewayException { }
public class PaymentGatewayUnavailableException extends PaymentGatewayException { }
public class StripeApiException extends PaymentGatewayException { }
 
// Pattern: {Operation}FailedException (when operation name is clearer)
public class SerializationFailedException extends TechnicalException { }
public class EncryptionFailedException extends TechnicalException { }
public class FileUploadFailedException extends TechnicalException { }

Error Code Design

Error codes are machine-readable identifiers that support monitoring, alerting, documentation, and client-side handling. Good error codes are hierarchical, consistent, and stable across releases.

Error Code Structure

Recommended Pattern: {DOMAIN}.{CATEGORY}.{SPECIFIC}

Error Code Components
Component	Purpose	Examples
Domain	Which business domain or system	`ORDER`, `USER`, `PAYMENT`, `AUTH`
Category	Type of failure within domain	`VALIDATION`, `NOT_FOUND`, `CONFLICT`, `GATEWAY`
Specific	Exact failure condition	`AMOUNT_NEGATIVE`, `EMAIL_TAKEN`, `TIMEOUT`

Error Code Examples

Examples

# Error Code Hierarchy Examples
 
ORDER.NOT_FOUND                      # Order doesn't exist
ORDER.VALIDATION.ITEMS_EMPTY         # Order has no items
ORDER.VALIDATION.AMOUNT_NEGATIVE     # Invalid amount
ORDER.CONFLICT.ALREADY_SUBMITTED     # Can't modify submitted order
ORDER.CONFLICT.ALREADY_CANCELLED     # Already cancelled
ORDER.INVENTORY.INSUFFICIENT         # Not enough stock
ORDER.SHIPPING.ADDRESS_REQUIRED      # Missing address
 
USER.NOT_FOUND                       # User doesn't exist
USER.VALIDATION.EMAIL_INVALID        # Bad email format
USER.VALIDATION.PASSWORD_WEAK        # Password doesn't meet requirements
USER.CONFLICT.EMAIL_TAKEN            # Email already registered
USER.STATE.SUSPENDED                 # Account suspended
USER.STATE.NOT_VERIFIED              # Email not verified
 
PAYMENT.DECLINED                     # Generic decline
PAYMENT.DECLINED.INSUFFICIENT_FUNDS  # Specific: not enough money
PAYMENT.DECLINED.CARD_EXPIRED        # Specific: card expired
PAYMENT.DECLINED.FRAUD_SUSPECTED     # Specific: fraud check failed
PAYMENT.GATEWAY.TIMEOUT              # Gateway didn't respond
PAYMENT.GATEWAY.UNAVAILABLE          # Gateway is down
PAYMENT.CAPTURE.ALREADY_CAPTURED     # Can't capture twice
 
AUTH.INVALID_CREDENTIALS             # Wrong username/password
AUTH.TOKEN.EXPIRED                   # Token past expiry
AUTH.TOKEN.INVALID                   # Token malformed/tampered
AUTH.PERMISSION.DENIED               # Not authorized
AUTH.RATE_LIMITED                    # Too many attempts
 
INFRA.DATABASE.CONNECTION_FAILED     # Can't connect to DB
INFRA.DATABASE.TIMEOUT               # Query took too long
INFRA.CACHE.UNAVAILABLE              # Cache is down
INFRA.MESSAGING.PUBLISH_FAILED       # Message publish failed

Error Code Best Practices

•Use SCREAMING_SNAKE_CASE — Distinguishes from regular text; standard for constants
•Keep domains stable — Don't rename domains; clients may depend on them
•Document publicly-exposed codes — API contracts should list possible error codes
•Use prefixes for filtering — ORDER.* matches all order errors in monitoring
•Avoid numbers — ERROR_42 means nothing; ORDER.NOT_FOUND is self-documenting
•Be consistent — If you use .NOT_FOUND for one entity, use it for all

Error Code Implementation
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
/**
 * Centralized error code constants.
 * Provides type safety, discoverability, and documentation.
 */
public final class ErrorCodes {
    
    private ErrorCodes() {} // Utility class
    
    // ==========================================
    // ORDER DOMAIN
    // ==========================================
    public static final class Order {
        private static final String PREFIX = "ORDER.";
        
        public static final String NOT_FOUND = PREFIX + "NOT_FOUND";
        
        public static final class Validation {
            private static final String PREFIX = Order.PREFIX + "VALIDATION.";
            
            public static final String ITEMS_EMPTY = PREFIX + "ITEMS_EMPTY";
            public static final String AMOUNT_NEGATIVE = PREFIX + "AMOUNT_NEGATIVE";
            public static final String QUANTITY_INVALID = PREFIX + "QUANTITY_INVALID";
        }
        
        public static final class Conflict {
            private static final String PREFIX = Order.PREFIX + "CONFLICT.";
            
            public static final String ALREADY_SUBMITTED = PREFIX + "ALREADY_SUBMITTED";
            public static final String ALREADY_CANCELLED = PREFIX + "ALREADY_CANCELLED";
            public static final String CONCURRENT_MODIFICATION = PREFIX + "CONCURRENT_MODIFICATION";
        }
        
        public static final class Inventory {
            private static final String PREFIX = Order.PREFIX + "INVENTORY.";
            
            public static final String INSUFFICIENT = PREFIX + "INSUFFICIENT";
            public static final String RESERVED = PREFIX + "RESERVED";
        }
    }
    
    // ==========================================
    // USER DOMAIN
    // ==========================================
    public static final class User {
        private static final String PREFIX = "USER.";
        
        public static final String NOT_FOUND = PREFIX + "NOT_FOUND";
        
        public static final class Validation {
            private static final String PREFIX = User.PREFIX + "VALIDATION.";
            
            public static final String EMAIL_INVALID = PREFIX + "EMAIL_INVALID";
            public static final String PASSWORD_WEAK = PREFIX + "PASSWORD_WEAK";
        }
        
        public static final class Conflict {
            private static final String PREFIX = User.PREFIX + "CONFLICT.";
            
            public static final String EMAIL_TAKEN = PREFIX + "EMAIL_TAKEN";
            public static final String USERNAME_TAKEN = PREFIX + "USERNAME_TAKEN";
        }
    }
    
    // Usage in exceptions:
    // throw new OrderNotFoundException(orderId, ErrorCodes.Order.NOT_FOUND);
    // throw new ValidationException(errors, ErrorCodes.Order.Validation.ITEMS_EMPTY);
}

Message Formatting Guidelines

Exception messages appear in logs, monitoring dashboards, and sometimes error responses. They should be consistently formatted, information-rich, and safe to display.

Message Construction Patterns

Build messages from exception data rather than accepting raw strings. This ensures consistency and prevents information omission.

Message Construction Patterns
Java
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
public class OrderNotFoundException extends OrderException {
    
    // ❌ BAD: Accept raw message (inconsistent, error-prone)
    public OrderNotFoundException(String message) {
        super(message);  // Caller might forget order ID!
    }
    
    // ✅ GOOD: Build message from structured data
    public OrderNotFoundException(OrderId orderId) {
        super(
            buildMessage(orderId),  // Consistent message
            ErrorCodes.Order.NOT_FOUND,
            orderId
        );
    }
    
    // ✅ GOOD: Optional lookup context for richer messages
    public OrderNotFoundException(OrderId orderId, LookupContext context) {
        super(
            buildMessageWithContext(orderId, context),
            ErrorCodes.Order.NOT_FOUND,
            orderId
        );
    }
    
    private static String buildMessage(OrderId orderId) {
        return format("Order not found: %s", orderId.value());
    }
    
    private static String buildMessageWithContext(OrderId orderId, LookupContext ctx) {
        return format("Order %s not found (looked up by: %s, user: %s)",
            orderId.value(),
            ctx.lookupMethod(),
            ctx.requestingUserId()
        );
    }
}
 
 
// =====================================================
// MESSAGE TEMPLATES FOR CONSISTENCY
// =====================================================
 
public final class MessageTemplates {
    
    // Entity not found messages
    public static String entityNotFound(String entityType, String id) {
        return format("%s not found: %s", entityType, id);
    }
    
    // Conflict messages
    public static String alreadyExists(String entityType, String field, String value) {
        return format("%s with %s '%s' already exists", entityType, field, value);
    }
    
    public static String alreadyInState(String entityType, String id, String state) {
        return format("%s %s is already %s", entityType, id, state);
    }
    
    // Validation messages
    public static String fieldInvalid(String field, String reason) {
        return format("Invalid value for '%s': %s", field, reason);
    }
    
    public static String fieldRequired(String field) {
        return format("Field '%s' is required", field);
    }
    
    // Insufficient resource messages
    public static String insufficientResource(String resource, Object required, Object available) {
        return format("Insufficient %s: required %s, available %s", 
            resource, required, available);
    }
    
    // Technical failure messages
    public static String serviceUnavailable(String serviceName) {
        return format("Service unavailable: %s", serviceName);
    }
    
    public static String operationTimeout(String operation, Duration timeout) {
        return format("Operation '%s' timed out after %s", operation, timeout);
    }
}
 
// Usage:
throw new UserNotFoundException(userId);  // Uses: "User not found: {id}"
throw new InsufficientFundsException(
    MessageTemplates.insufficientResource("funds", required, available),
    paymentId
);

Message Formatting Rules

•Include identifiers — Always include entity IDs, correlation IDs, or other lookup keys
•State facts, not actions — 'Order not found' not 'Please check order ID'
•Use consistent structure — '{Entity} not found: {id}' across all not-found exceptions
•No sensitive data — Never include passwords, tokens, or full credit card numbers
•Be concise — Log context separately; messages should be scannable
•Consider log parsing — Consistent structure enables log analysis and alerting

Sensitive Data in Messages

Naming Across Languages and Teams

Language-Specific Conventions
Language	Class Suffix	Case Style	Example
Java	`Exception`	PascalCase	`UserNotFoundException`
C#	`Exception`	PascalCase	`UserNotFoundException`
Python	`Error`	PascalCase	`UserNotFoundError`
TypeScript	`Error`	PascalCase	`UserNotFoundError`
Go	N/A (errors are values)	camelCase	`errUserNotFound`
Rust	`Error` (in enum)	PascalCase	`Error::UserNotFound`

Cross-Language Consistency Example
1
2
3
4
5
6
7
8
// Java: UserNotFoundException with error code USER.NOT_FOUND
public class UserNotFoundException extends EntityNotFoundException {
    public UserNotFoundException(UserId userId) {
        super("User not found: " + userId.value(), 
              "USER.NOT_FOUND",  // Same error code across all services
              userId.value());
    }
}

Cross-Team Standards Document

For organizations with multiple services, publish a naming standards document:

Exception Naming Standards (Example)
Markdown
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
# Exception Naming Standards
 
## Error Code Format
All error codes follow: `{DOMAIN}.{CATEGORY}.{SPECIFIC}`
 
### Reserved Domains
- ORDER - Order processing
- USER - User management  
- PAYMENT - Payment processing
- AUTH - Authentication/authorization
- INFRA - Infrastructure
 
### Standard Categories
- NOT_FOUND - Entity doesn't exist (→ HTTP 404)
- VALIDATION - Input validation failed (→ HTTP 400)
- CONFLICT - State conflict (→ HTTP 409)
- STATE - Invalid state transition (→ HTTP 422)
- GATEWAY - External service issue (→ HTTP 503)
 
### Class Naming
- Java/C#: `{Entity}{Issue}Exception`
- Python/TS: `{Entity}{Issue}Error`
- Follow domain's existing patterns
 
### Message Format
- Format: "{Entity} {action/state}: {details}"
- Include relevant IDs
- No sensitive data
- State facts, not actions
 
### Examples
| Error Code | Java Class | Message |
|------------|------------|---------|
| USER.NOT_FOUND | UserNotFoundException | User not found: usr_123 |
| ORDER.CONFLICT.ALREADY_CANCELLED | OrderAlreadyCancelledException | Order ord_456 was already cancelled |
| PAYMENT.DECLINED.INSUFFICIENT_FUNDS | InsufficientFundsException | Payment declined: insufficient funds for $50.00 |

Common Naming Mistakes

Even experienced developers make naming mistakes. Here are the most common anti-patterns and their fixes:

Common Naming Mistakes and Fixes
Mistake	Why It's Bad	Better Alternative
`MyAppException`	Every exception is "your app's"; no information	`OrderValidationException`
`Error1`, `Error2`	Completely meaningless	`UserNotFoundException`, `PaymentDeclinedException`
`GenericException`	Admits it's generic—so why use it?	Use specific subtypes
`DatabaseException` for all DB issues	Lumps together distinct failures	`ConnectionTimeoutException`, `ConstraintViolationException`
`BadRequestException`	HTTP-centric; domain layer shouldn't know HTTP	`ValidationException`, `MissingFieldException`
`check if user exist exception`	Not a valid class name format	`UserExistenceCheckException` or better: `UserNotFoundException`
Error code: `42`	Numbers without context are useless	`USER.NOT_FOUND`
Error code: `userNotFound`	Inconsistent casing, no hierarchy	`USER.NOT_FOUND`
Message: `Error`	Says literally nothing	`User not found: usr_123`
Message: `Something went wrong`	Completely unhelpful for debugging	`Payment capture failed: gateway timeout after 30s`

Naming Anti-Pattern Examples
Java
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
// ❌ ANTI-PATTERN: Vague generic names
public class DataException extends Exception { }
public class ServiceException extends Exception { }
public class ProcessException extends Exception { }
// What data? Which service? What process?
 
// ❌ ANTI-PATTERN: Implementation details in names
public class DatabaseSQLIntegrityConstraintViolationException { }
public class HttpClientConnectionPoolTimeoutException { }
// Too long; exposes implementation
 
// ❌ ANTI-PATTERN: Action-oriented names
public class RetryLaterException extends Exception { }
public class ContactSupportException extends Exception { }
public class FixYourInputException extends Exception { }
// Names should describe WHAT happened, not WHAT TO DO
 
// ❌ ANTI-PATTERN: Negative-only names
public class NotOkException extends Exception { }
public class InvalidException extends Exception { }
public class FailureException extends Exception { }
// What exactly isn't ok/valid/failed?
 
// ❌ ANTI-PATTERN: Redundant naming
public class ExceptionException extends Exception { }  // Seriously?
public class ErrorExceptionError extends Exception { } // Worse
public class UserExceptionUserFailed extends Exception { } // Confused
 
 
// ✅ GOOD: Clear, specific, domain-oriented names
public class UserNotFoundException extends EntityNotFoundException { }
public class PaymentGatewayTimeoutException extends TechnicalException { }
public class InsufficientInventoryException extends OrderException { }
public class EmailAlreadyRegisteredException extends ConflictException { }
public class PasswordStrengthInsufficientException extends ValidationException { }

The New Team Member Test

Summary: Naming Conventions

Key Takeaways

•Class names describe what happened — InsufficientFundsException not AddFundsException
•Follow category patterns — {Entity}NotFoundException, {Entity}AlreadyExistsException, etc.
•Error codes are hierarchical — DOMAIN.CATEGORY.SPECIFIC (e.g., ORDER.INVENTORY.INSUFFICIENT)
•Error codes are stable — They're API contracts; don't change without versioning
•Messages are constructed, not accepted — Build from structured data for consistency
•Messages include identifiers — Always include order ID, user ID, etc. for tracing
•Maintain cross-team consistency — Same error codes across services enable unified monitoring

Module Complete!

You've now learned the complete discipline of exception hierarchy design:

Base Exception Classes — The foundation of your hierarchy, integrating with language conventions
Custom Exception Classes — Domain-specific types with rich, actionable information
Exception Categorization — Organizing exceptions for handling, monitoring, and documentation
Naming Conventions — Making exceptions self-documenting through precise, consistent naming

With these skills, you can design exception systems that make error handling clear, debugging efficient, and operations transparent.

Module Complete

4 / 4