System Design (LLD)Exception Handling Best Practices

Exception Handling Best Practices

LevelIntermediate

Duration60 mins

TopicException Handling Best Practices

2 / 4

Don't Swallow Exceptions

The Silent Killer in Your Codebase

There is an anti-pattern so dangerous, so insidious, that it has earned its own name in the software engineering lexicon: exception swallowing. It occurs when a developer catches an exception and then... does nothing. The exception vanishes without a trace, no log, no rethrow, no indication that anything went wrong.

Exception swallowing is the software equivalent of a smoke detector with dead batteries. The detector exists, but when fire breaks out, you never know until it's too late. Systems that swallow exceptions appear to work correctly—until they catastrophically fail in ways that nobody can diagnose.

The Gravity of This Anti-Pattern

Exception swallowing is not merely a code smell or stylistic preference. It is a critical defect that renders your system unobservable, undebuggable, and unreliable. Every swallowed exception is a potential production incident waiting to happen—with no trail to follow when it does.

What You Will Learn

By the end of this page, you will understand why exception swallowing is so dangerous, learn to identify its various manifestations, and master the techniques for ensuring that every exception produces a visible, actionable signal.

Anatomy of Exception Swallowing

Exception swallowing takes many forms, from blatantly obvious to deceptively subtle. Let's examine the spectrum:

SwallowingExamples
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
// THE SPECTRUM OF EXCEPTION SWALLOWING
 
// ❌ LEVEL 1: THE EMPTY CATCH (Blatantly Obvious)
// The classic, unmistakable anti-pattern
try {
    performCriticalOperation();
} catch (Exception e) {
    // Nothing here. Absolutely nothing.
}
 
// ❌ LEVEL 2: THE TODO GRAVEYARD (Developer Intention)
// "I'll fix this later" - narrator: they didn't
try {
    saveUserData(data);
} catch (IOException e) {
    // TODO: handle this properly
}
 
// ❌ LEVEL 3: THE SILENT PRINT (False Observability)
// Looks like logging but goes nowhere visible
try {
    processPayment(order);
} catch (PaymentException e) {
    System.out.println("Error: " + e.getMessage());  // Lost to stdout
}
 
// ❌ LEVEL 4: THE MISLEADING RETURN (Hidden Control Flow)
// Exception is caught but program continues with wrong data
public User findUser(String id) {
    try {
        return userRepository.findById(id);
    } catch (DataAccessException e) {
        return null;  // Caller has no idea something went wrong
    }
}
 
// ❌ LEVEL 5: THE FALSE LOG (Inadequate Context)
// Logs but loses critical diagnostic information
try {
    connectToDatabase();
} catch (SQLException e) {
    logger.error("Database error occurred");  // No exception, no stack trace
}
 
// ❌ LEVEL 6: THE RETHROW DISGUISER (Information Destruction)
// Catches one exception, throws another, loses cause
try {
    parseConfiguration(config);
} catch (ConfigParseException e) {
    throw new RuntimeException("Config error");  // Original cause lost!
}

All Levels Are Dangerous

Every level on this spectrum represents a failure mode. The difference is only in how quickly you'll discover the problem. Empty catches fail silently for years. Inadequate logging fails when you need to debug a production incident at 3 AM.

Why Developers Swallow Exceptions

Understanding why exception swallowing happens is essential to eliminating it. Nobody writes empty catch blocks with malicious intent. They do it for seemingly rational reasons that are actually flawed:

Common Rationalizations and Their Rebuttals
Rationalization	Reality	Proper Response
"This exception can't actually happen"	If it truly can't happen, the JVM/runtime won't throw it. If the compiler requires handling, there's a reason.	If genuinely impossible, throw AssertionError/unreachable with explanation
"I'll handle it properly later"	Technical debt accrues interest. That 'later' becomes 'never' 95% of the time.	Handle it now, even if basic. Use a TODO with ticket reference.
"The exception is not important"	You don't know what's important until something breaks. All exceptions are signals.	At minimum, log at DEBUG level. Let observability systems decide importance.
"I don't want to clutter the logs"	Cluttered logs are fixable. Missing logs during incidents are catastrophic.	Use structured logging with levels. Filter later, not at write time.
"The calling code can't handle errors anyway"	Then propagate up until you reach code that can. That's what exception propagation is for.	Let exceptions bubble. Handle at system boundaries.
"It's just a checked exception the API forces me to handle"	The API designer had a reason. Checked exceptions signal recoverable conditions.	Wrap in unchecked if truly unrecoverable, but include original cause.

The Core Fallacy: Every rationalization assumes the developer knows, at development time, which exceptions are important. But exceptions are signals about runtime conditions. You cannot know which signals matter until you observe the system in production under real load with real data.

The Observability Principle

Treat every exception as potentially important diagnostic information. The cost of logging an unimportant exception is negligible. The cost of missing a critical exception is a production incident with no debugging trail.

The Real Cost of Swallowing

Exception swallowing doesn't just hide immediate errors—it creates cascading failures that manifest far from the original problem. Let's trace through a realistic scenario:

CascadingFailure
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
/**
 * A realistic scenario showing how swallowed exceptions cascade
 * into production nightmares.
 */
 
// STEP 1: A developer swallows an exception "because it rarely happens"
public class UserPreferencesService {
    public void updatePreferences(String userId, Preferences prefs) {
        try {
            preferencesCache.update(userId, prefs);  // Step 1
            database.writePreferences(userId, prefs); // Step 2
        } catch (CacheUpdateException e) {
            // "Cache failures are transient, it'll fix itself"
            // ❌ SWALLOWED - no log, no metrics, nothing
        }
    }
}
 
// STEP 2: Hours later, the cache and database are out of sync
// Cache still has old preferences, database has new ones
 
// STEP 3: Another service reads from cache (because it's fast)
public class RecommendationService {
    public List<Product> getRecommendations(String userId) {
        Preferences prefs = preferencesCache.get(userId);  // Gets STALE data
        return generateRecommendations(prefs);  // Wrong recommendations
    }
}
 
// STEP 4: User sees wrong recommendations
// User reports: "Your recommendations are terrible"
// Support: "Sorry, we'll look into it"
 
// STEP 5: Engineering investigates
// - Recommendation algorithm looks correct ✓
// - User preferences in database look correct ✓
// - Cache data... wait, where are the cache logs?
// - No exception logs, no metrics, NO TRAIL
 
// STEP 6: After 3 days of investigation
// "We have no idea what happened. We'll monitor it."
 
// STEP 7: Problem continues for months
// User churn increases 15%
// Nobody connects it to that one swallowed exception

Concrete Business Costs

•Engineering Time — Debugging without logs is archaeology. What takes 10 minutes with logs takes days without.
•Customer Impact — Silent failures affect users who never report. For every complaint, 10 users silently churned.
•Data Corruption — Swallowed exceptions during writes create inconsistent state that propagates through the system.
•Security Blindness — Swallowed security exceptions (failed auth, unauthorized access) mean active attacks go undetected.
•Compliance Violations — Audit requirements often mandate logging of failures. Swallowing may violate regulations.
•Incident Duration — MTTR (Mean Time To Recovery) increases dramatically when there's no diagnostic trail.

The Invisible Problem

The most insidious aspect of exception swallowing is that you don't know it's happening. The system appears healthy. Metrics look normal. Then one day, you discover that for the past 6 months, 5% of user data updates silently failed—and you have no way to identify which ones.

The Exception Handling Contract

To prevent exception swallowing, adopt a simple contract: Every caught exception MUST result in at least one of these four actions:

The Four Valid Exception Responses

•Log the exception — With full context: message, stack trace, relevant variables, correlation IDs.
•Rethrow the exception — Either the original, or wrapped in a more appropriate type with the original as cause.
•Return an error indicator — Result type, error code, or status object that signals failure to the caller.
•Self-heal and log the recovery — Take corrective action AND log that recovery occurred.

Notice what's NOT on this list: Ignoring, suppressing, or silently continuing. There is no fifth option.

ExceptionContract
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
/**
 * Demonstration of the four valid exception responses.
 */
public class ExceptionContractExamples {
 
    // RESPONSE 1: LOG WITH FULL CONTEXT
    // Use when: Exception is informational, operation can continue
    public void logExample() {
        try {
            refreshCacheInBackground();
        } catch (CacheRefreshException e) {
            logger.warn("Cache refresh failed, using stale data. " +
                        "CacheId={}, LastRefresh={}, Reason={}",
                        cacheId, lastRefreshTime, e.getMessage(), e);
            // Operation continues with stale cache
            metrics.increment("cache.refresh.failures");
        }
    }
    
    // RESPONSE 2: RETHROW (optionally wrapped)
    // Use when: Current method cannot handle, caller might
    public User loadUser(String userId) throws DataAccessException {
        try {
            return database.query("SELECT * FROM users WHERE id = ?", userId);
        } catch (SQLException e) {
            // Wrap in domain exception, preserve original cause
            throw new DataAccessException(
                "Failed to load user: " + userId, e);
        }
    }
    
    // RESPONSE 3: RETURN ERROR INDICATOR
    // Use when: Error is expected, caller needs structured response
    public Result<Order, OrderError> createOrder(OrderRequest request) {
        try {
            Order order = orderService.create(request);
            return Result.success(order);
        } catch (InsufficientInventoryException e) {
            logger.info("Order failed due to inventory: {} for SKUs {}",
                        request.getId(), e.getAffectedSkus());
            return Result.failure(
                new OrderError(OrderErrorCode.INSUFFICIENT_INVENTORY,
                              e.getAffectedSkus()));
        }
    }
    
    // RESPONSE 4: SELF-HEAL AND LOG RECOVERY
    // Use when: Exception is recoverable through alternative action
    public Connection getConnection() throws ServiceUnavailableException {
        try {
            return primaryPool.acquire();
        } catch (PoolExhaustedException e) {
            logger.warn("Primary pool exhausted, failing over to secondary. " +
                        "PoolSize={}, WaitingRequests={}", 
                        primaryPool.size(), primaryPool.waiting(), e);
            metrics.increment("pool.failover.count");
            
            try {
                return secondaryPool.acquire();
            } catch (PoolExhaustedException e2) {
                // Secondary also exhausted - now we truly can't handle
                throw new ServiceUnavailableException(
                    "All connection pools exhausted", e2);
            }
        }
    }
    
    // ❌ NEVER: The empty/silent catch
    public void neverDoThis() {
        try {
            importantOperation();
        } catch (Exception e) {
            // This is NEVER acceptable
        }
    }
}

Proper Logging Patterns

If logging is one of the four valid responses, then logging correctly is essential. Bad logging is almost as harmful as no logging.

Bad Exception Logging

•logger.error("Error")
•logger.error(e.getMessage())
•logger.error("Error: " + e)
•System.out.println(e)
•No correlation IDs
•No contextual data
•Wrong log level

Good Exception Logging

•Full exception object passed to logger
•Structured fields for context
•Correlation/request/trace IDs
•Relevant business identifiers
•Appropriate log level
•Actionable message
•No sensitive data in logs

LoggingPatterns
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
/**
 * Demonstration of proper exception logging patterns.
 */
public class LoggingPatterns {
    
    // ❌ BAD: No useful information
    public void badLogging1() {
        try { operation(); }
        catch (Exception e) {
            logger.error("Error");  // ❌ What error? Where? Why?
        }
    }
    
    // ❌ BAD: Loses stack trace
    public void badLogging2() {
        try { operation(); }
        catch (Exception e) {
            logger.error("Error: " + e.getMessage());  // ❌ No stack trace!
        }
    }
    
    // ❌ BAD: Wrong level
    public void badLogging3() {
        try { criticalPaymentProcess(); }
        catch (PaymentException e) {
            logger.debug("Payment failed", e);  // ❌ DEBUG?! This is critical!
        }
    }
    
    // ✅ GOOD: Complete context, structured logging
    public void goodLogging() {
        String orderId = order.getId();
        String userId = user.getId();
        BigDecimal amount = order.getTotal();
        
        try {
            paymentGateway.charge(order);
        } catch (PaymentDeclinedException e) {
            // Expected business error - INFO level
            logger.info("Payment declined for order. OrderId={}, UserId={}, Amount={}, " +
                       "DeclineCode={}, TraceId={}",
                       orderId, userId, amount, e.getDeclineCode(), 
                       MDC.get("traceId"), e);
            
        } catch (PaymentGatewayException e) {
            // Infrastructure failure - ERROR level  
            logger.error("Payment gateway failure. OrderId={}, UserId={}, Amount={}, " +
                        "Gateway={}, TraceId={}",
                        orderId, userId, amount, gatewayName,
                        MDC.get("traceId"), e);  // Note: exception is LAST parameter
            
            // Also emit metric for alerting
            metrics.increment("payment.gateway.errors",
                Tags.of("gateway", gatewayName, "error_type", e.getClass().getSimpleName()));
        }
    }
    
    // ✅ GOOD: Structured logging with log aggregation compatibility
    @WithSpan  // OpenTelemetry trace annotation
    public void structuredLogging(OrderRequest request) {
        try {
            processOrder(request);
        } catch (OrderProcessingException e) {
            // Structured logging for ELK/Splunk/CloudWatch
            logger.error("Order processing failed", 
                StructuredArguments.kv("orderId", request.getId()),
                StructuredArguments.kv("customerId", request.getCustomerId()),
                StructuredArguments.kv("productCount", request.getItems().size()),
                StructuredArguments.kv("failureReason", e.getReason()),
                StructuredArguments.kv("traceId", Span.current().getSpanContext().getTraceId()),
                e);  // Exception always last
        }
    }
}

Log Level Guidelines

ERROR: Infrastructure failures, unexpected exceptions, conditions requiring investigation. WARN: Expected problems handled gracefully (retries, fallbacks). INFO: Business events including expected rejections (payment declined, validation failed). DEBUG: Detailed diagnostic info not needed in production.

Detection and Prevention

Exception swallowing often slips into codebases gradually. Establishing automated detection and team practices is essential.

DetectionTools
Config
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
# Static Analysis Configuration Examples
 
# Java - SpotBugs (FindBugs successor)
# spotbugs-exclude.xml - DO NOT exclude these detectors!
# REC_CATCH_EXCEPTION: method catches Exception
# DE_MIGHT_IGNORE: dead exception - catch/return with no use
 
# Java - Error Prone (Google's static analysis)
# build.gradle
compileJava {
    options.errorprone.error("EmptyCatch")
    options.errorprone.error("CatchAndPrintStackTrace")
}
 
# C# - .editorconfig rules
[*.cs]
# CA2200: Rethrow to preserve stack details
dotnet_diagnostic.CA2200.severity = error
# CA1031: Do not catch general exception types
dotnet_diagnostic.CA1031.severity = warning
 
# ESLint for TypeScript
# .eslintrc.js
{
  rules: {
    "no-empty": ["error", { "allowEmptyCatch": false }],
    "@typescript-eslint/no-empty-function": "error",
  }
}
 
# Python - pylint
# .pylintrc
[MESSAGES CONTROL]
enable=bare-except,broad-except
 
# SonarQube rules (multi-language)
# These rules should be enabled and set to "Blocker":
# - java:S108  - Nested blocks of code should not be empty
# - java:S2142 - InterruptedException should not be ignored
# - java:S1166 - Exception handlers should preserve original exceptions
# - cs:S108   - Nested blocks should not be empty
# - ts:S108   - Nested blocks should not be empty

Prevention Practices

•CI/CD Gates — Configure static analysis to fail builds on empty catch blocks. No exceptions (pun intended).
•Code Review Checklist — Add 'No swallowed exceptions' as mandatory review criterion.
•Team Education — Ensure all team members understand the four valid responses to exceptions.
•Codebase Audits — Periodically search for catch (Exception with no following log/throw statements.
•IDE Configuration — Configure IDE to warn on empty catch blocks (IntelliJ, VS, VSCode all support this).
•Pre-commit Hooks — Add git hooks that scan for obvious swallowing patterns before commit.

Zero Tolerance Policy

Adopt a zero-tolerance policy for empty catch blocks. If code review finds one, it's a blocking comment. If it slips into production, create a bug ticket immediately. The cultural norm should be: swallowed exceptions are always bugs.

Summary: Never Swallow Exceptions

Exception swallowing is one of the most destructive anti-patterns in software development. Let's consolidate the key lessons:

Key Takeaways

•Exception swallowing creates invisible failures — Systems appear healthy while silently corrupting data, losing transactions, and frustrating users.
•Every exception must produce a signal — The four valid responses: log, rethrow, return error indicator, or self-heal with logging.
•Developer rationalizations are flawed — You cannot know at development time which exceptions will matter in production.
•Bad logging is nearly as bad as no logging — Include stack traces, context, correlation IDs, and appropriate log levels.
•Static analysis prevents swallowing — Configure tools to fail builds on empty catches. Treat violations as blocking bugs.
•Zero tolerance culture is essential — Make the team expectation clear: swallowed exceptions are never acceptable.

Coming Up Next

The next page explores exception wrapping and chaining—the techniques for enriching exceptions with context as they propagate through system layers while preserving the original diagnostic information.

2 / 4

Loading learning content...

System Design (LLD)Exception Handling Best Practices

Exception Handling Best Practices

LevelIntermediate

Duration60 mins

TopicException Handling Best Practices

2 / 4

Don't Swallow Exceptions

The Silent Killer in Your Codebase

The Gravity of This Anti-Pattern

What You Will Learn

Anatomy of Exception Swallowing

Exception swallowing takes many forms, from blatantly obvious to deceptively subtle. Let's examine the spectrum:

SwallowingExamples
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
// THE SPECTRUM OF EXCEPTION SWALLOWING
 
// ❌ LEVEL 1: THE EMPTY CATCH (Blatantly Obvious)
// The classic, unmistakable anti-pattern
try {
    performCriticalOperation();
} catch (Exception e) {
    // Nothing here. Absolutely nothing.
}
 
// ❌ LEVEL 2: THE TODO GRAVEYARD (Developer Intention)
// "I'll fix this later" - narrator: they didn't
try {
    saveUserData(data);
} catch (IOException e) {
    // TODO: handle this properly
}
 
// ❌ LEVEL 3: THE SILENT PRINT (False Observability)
// Looks like logging but goes nowhere visible
try {
    processPayment(order);
} catch (PaymentException e) {
    System.out.println("Error: " + e.getMessage());  // Lost to stdout
}
 
// ❌ LEVEL 4: THE MISLEADING RETURN (Hidden Control Flow)
// Exception is caught but program continues with wrong data
public User findUser(String id) {
    try {
        return userRepository.findById(id);
    } catch (DataAccessException e) {
        return null;  // Caller has no idea something went wrong
    }
}
 
// ❌ LEVEL 5: THE FALSE LOG (Inadequate Context)
// Logs but loses critical diagnostic information
try {
    connectToDatabase();
} catch (SQLException e) {
    logger.error("Database error occurred");  // No exception, no stack trace
}
 
// ❌ LEVEL 6: THE RETHROW DISGUISER (Information Destruction)
// Catches one exception, throws another, loses cause
try {
    parseConfiguration(config);
} catch (ConfigParseException e) {
    throw new RuntimeException("Config error");  // Original cause lost!
}

All Levels Are Dangerous

Why Developers Swallow Exceptions

Common Rationalizations and Their Rebuttals
Rationalization	Reality	Proper Response
"This exception can't actually happen"	If it truly can't happen, the JVM/runtime won't throw it. If the compiler requires handling, there's a reason.	If genuinely impossible, throw AssertionError/unreachable with explanation
"I'll handle it properly later"	Technical debt accrues interest. That 'later' becomes 'never' 95% of the time.	Handle it now, even if basic. Use a TODO with ticket reference.
"The exception is not important"	You don't know what's important until something breaks. All exceptions are signals.	At minimum, log at DEBUG level. Let observability systems decide importance.
"I don't want to clutter the logs"	Cluttered logs are fixable. Missing logs during incidents are catastrophic.	Use structured logging with levels. Filter later, not at write time.
"The calling code can't handle errors anyway"	Then propagate up until you reach code that can. That's what exception propagation is for.	Let exceptions bubble. Handle at system boundaries.
"It's just a checked exception the API forces me to handle"	The API designer had a reason. Checked exceptions signal recoverable conditions.	Wrap in unchecked if truly unrecoverable, but include original cause.

The Observability Principle

The Real Cost of Swallowing

Exception swallowing doesn't just hide immediate errors—it creates cascading failures that manifest far from the original problem. Let's trace through a realistic scenario:

CascadingFailure
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
/**
 * A realistic scenario showing how swallowed exceptions cascade
 * into production nightmares.
 */
 
// STEP 1: A developer swallows an exception "because it rarely happens"
public class UserPreferencesService {
    public void updatePreferences(String userId, Preferences prefs) {
        try {
            preferencesCache.update(userId, prefs);  // Step 1
            database.writePreferences(userId, prefs); // Step 2
        } catch (CacheUpdateException e) {
            // "Cache failures are transient, it'll fix itself"
            // ❌ SWALLOWED - no log, no metrics, nothing
        }
    }
}
 
// STEP 2: Hours later, the cache and database are out of sync
// Cache still has old preferences, database has new ones
 
// STEP 3: Another service reads from cache (because it's fast)
public class RecommendationService {
    public List<Product> getRecommendations(String userId) {
        Preferences prefs = preferencesCache.get(userId);  // Gets STALE data
        return generateRecommendations(prefs);  // Wrong recommendations
    }
}
 
// STEP 4: User sees wrong recommendations
// User reports: "Your recommendations are terrible"
// Support: "Sorry, we'll look into it"
 
// STEP 5: Engineering investigates
// - Recommendation algorithm looks correct ✓
// - User preferences in database look correct ✓
// - Cache data... wait, where are the cache logs?
// - No exception logs, no metrics, NO TRAIL
 
// STEP 6: After 3 days of investigation
// "We have no idea what happened. We'll monitor it."
 
// STEP 7: Problem continues for months
// User churn increases 15%
// Nobody connects it to that one swallowed exception

Concrete Business Costs

•Engineering Time — Debugging without logs is archaeology. What takes 10 minutes with logs takes days without.
•Customer Impact — Silent failures affect users who never report. For every complaint, 10 users silently churned.
•Data Corruption — Swallowed exceptions during writes create inconsistent state that propagates through the system.
•Security Blindness — Swallowed security exceptions (failed auth, unauthorized access) mean active attacks go undetected.
•Compliance Violations — Audit requirements often mandate logging of failures. Swallowing may violate regulations.
•Incident Duration — MTTR (Mean Time To Recovery) increases dramatically when there's no diagnostic trail.

The Invisible Problem

The Exception Handling Contract

To prevent exception swallowing, adopt a simple contract: Every caught exception MUST result in at least one of these four actions:

The Four Valid Exception Responses

•Log the exception — With full context: message, stack trace, relevant variables, correlation IDs.
•Rethrow the exception — Either the original, or wrapped in a more appropriate type with the original as cause.
•Return an error indicator — Result type, error code, or status object that signals failure to the caller.
•Self-heal and log the recovery — Take corrective action AND log that recovery occurred.

Notice what's NOT on this list: Ignoring, suppressing, or silently continuing. There is no fifth option.

ExceptionContract
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
/**
 * Demonstration of the four valid exception responses.
 */
public class ExceptionContractExamples {
 
    // RESPONSE 1: LOG WITH FULL CONTEXT
    // Use when: Exception is informational, operation can continue
    public void logExample() {
        try {
            refreshCacheInBackground();
        } catch (CacheRefreshException e) {
            logger.warn("Cache refresh failed, using stale data. " +
                        "CacheId={}, LastRefresh={}, Reason={}",
                        cacheId, lastRefreshTime, e.getMessage(), e);
            // Operation continues with stale cache
            metrics.increment("cache.refresh.failures");
        }
    }
    
    // RESPONSE 2: RETHROW (optionally wrapped)
    // Use when: Current method cannot handle, caller might
    public User loadUser(String userId) throws DataAccessException {
        try {
            return database.query("SELECT * FROM users WHERE id = ?", userId);
        } catch (SQLException e) {
            // Wrap in domain exception, preserve original cause
            throw new DataAccessException(
                "Failed to load user: " + userId, e);
        }
    }
    
    // RESPONSE 3: RETURN ERROR INDICATOR
    // Use when: Error is expected, caller needs structured response
    public Result<Order, OrderError> createOrder(OrderRequest request) {
        try {
            Order order = orderService.create(request);
            return Result.success(order);
        } catch (InsufficientInventoryException e) {
            logger.info("Order failed due to inventory: {} for SKUs {}",
                        request.getId(), e.getAffectedSkus());
            return Result.failure(
                new OrderError(OrderErrorCode.INSUFFICIENT_INVENTORY,
                              e.getAffectedSkus()));
        }
    }
    
    // RESPONSE 4: SELF-HEAL AND LOG RECOVERY
    // Use when: Exception is recoverable through alternative action
    public Connection getConnection() throws ServiceUnavailableException {
        try {
            return primaryPool.acquire();
        } catch (PoolExhaustedException e) {
            logger.warn("Primary pool exhausted, failing over to secondary. " +
                        "PoolSize={}, WaitingRequests={}", 
                        primaryPool.size(), primaryPool.waiting(), e);
            metrics.increment("pool.failover.count");
            
            try {
                return secondaryPool.acquire();
            } catch (PoolExhaustedException e2) {
                // Secondary also exhausted - now we truly can't handle
                throw new ServiceUnavailableException(
                    "All connection pools exhausted", e2);
            }
        }
    }
    
    // ❌ NEVER: The empty/silent catch
    public void neverDoThis() {
        try {
            importantOperation();
        } catch (Exception e) {
            // This is NEVER acceptable
        }
    }
}

Proper Logging Patterns

If logging is one of the four valid responses, then logging correctly is essential. Bad logging is almost as harmful as no logging.

Bad Exception Logging

•logger.error("Error")
•logger.error(e.getMessage())
•logger.error("Error: " + e)
•System.out.println(e)
•No correlation IDs
•No contextual data
•Wrong log level

Good Exception Logging

•Full exception object passed to logger
•Structured fields for context
•Correlation/request/trace IDs
•Relevant business identifiers
•Appropriate log level
•Actionable message
•No sensitive data in logs

LoggingPatterns
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
/**
 * Demonstration of proper exception logging patterns.
 */
public class LoggingPatterns {
    
    // ❌ BAD: No useful information
    public void badLogging1() {
        try { operation(); }
        catch (Exception e) {
            logger.error("Error");  // ❌ What error? Where? Why?
        }
    }
    
    // ❌ BAD: Loses stack trace
    public void badLogging2() {
        try { operation(); }
        catch (Exception e) {
            logger.error("Error: " + e.getMessage());  // ❌ No stack trace!
        }
    }
    
    // ❌ BAD: Wrong level
    public void badLogging3() {
        try { criticalPaymentProcess(); }
        catch (PaymentException e) {
            logger.debug("Payment failed", e);  // ❌ DEBUG?! This is critical!
        }
    }
    
    // ✅ GOOD: Complete context, structured logging
    public void goodLogging() {
        String orderId = order.getId();
        String userId = user.getId();
        BigDecimal amount = order.getTotal();
        
        try {
            paymentGateway.charge(order);
        } catch (PaymentDeclinedException e) {
            // Expected business error - INFO level
            logger.info("Payment declined for order. OrderId={}, UserId={}, Amount={}, " +
                       "DeclineCode={}, TraceId={}",
                       orderId, userId, amount, e.getDeclineCode(), 
                       MDC.get("traceId"), e);
            
        } catch (PaymentGatewayException e) {
            // Infrastructure failure - ERROR level  
            logger.error("Payment gateway failure. OrderId={}, UserId={}, Amount={}, " +
                        "Gateway={}, TraceId={}",
                        orderId, userId, amount, gatewayName,
                        MDC.get("traceId"), e);  // Note: exception is LAST parameter
            
            // Also emit metric for alerting
            metrics.increment("payment.gateway.errors",
                Tags.of("gateway", gatewayName, "error_type", e.getClass().getSimpleName()));
        }
    }
    
    // ✅ GOOD: Structured logging with log aggregation compatibility
    @WithSpan  // OpenTelemetry trace annotation
    public void structuredLogging(OrderRequest request) {
        try {
            processOrder(request);
        } catch (OrderProcessingException e) {
            // Structured logging for ELK/Splunk/CloudWatch
            logger.error("Order processing failed", 
                StructuredArguments.kv("orderId", request.getId()),
                StructuredArguments.kv("customerId", request.getCustomerId()),
                StructuredArguments.kv("productCount", request.getItems().size()),
                StructuredArguments.kv("failureReason", e.getReason()),
                StructuredArguments.kv("traceId", Span.current().getSpanContext().getTraceId()),
                e);  // Exception always last
        }
    }
}

Log Level Guidelines

Detection and Prevention

Exception swallowing often slips into codebases gradually. Establishing automated detection and team practices is essential.

DetectionTools
Config
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
# Static Analysis Configuration Examples
 
# Java - SpotBugs (FindBugs successor)
# spotbugs-exclude.xml - DO NOT exclude these detectors!
# REC_CATCH_EXCEPTION: method catches Exception
# DE_MIGHT_IGNORE: dead exception - catch/return with no use
 
# Java - Error Prone (Google's static analysis)
# build.gradle
compileJava {
    options.errorprone.error("EmptyCatch")
    options.errorprone.error("CatchAndPrintStackTrace")
}
 
# C# - .editorconfig rules
[*.cs]
# CA2200: Rethrow to preserve stack details
dotnet_diagnostic.CA2200.severity = error
# CA1031: Do not catch general exception types
dotnet_diagnostic.CA1031.severity = warning
 
# ESLint for TypeScript
# .eslintrc.js
{
  rules: {
    "no-empty": ["error", { "allowEmptyCatch": false }],
    "@typescript-eslint/no-empty-function": "error",
  }
}
 
# Python - pylint
# .pylintrc
[MESSAGES CONTROL]
enable=bare-except,broad-except
 
# SonarQube rules (multi-language)
# These rules should be enabled and set to "Blocker":
# - java:S108  - Nested blocks of code should not be empty
# - java:S2142 - InterruptedException should not be ignored
# - java:S1166 - Exception handlers should preserve original exceptions
# - cs:S108   - Nested blocks should not be empty
# - ts:S108   - Nested blocks should not be empty

Prevention Practices

•CI/CD Gates — Configure static analysis to fail builds on empty catch blocks. No exceptions (pun intended).
•Code Review Checklist — Add 'No swallowed exceptions' as mandatory review criterion.
•Team Education — Ensure all team members understand the four valid responses to exceptions.
•Codebase Audits — Periodically search for catch (Exception with no following log/throw statements.
•IDE Configuration — Configure IDE to warn on empty catch blocks (IntelliJ, VS, VSCode all support this).
•Pre-commit Hooks — Add git hooks that scan for obvious swallowing patterns before commit.

Zero Tolerance Policy

Summary: Never Swallow Exceptions

Exception swallowing is one of the most destructive anti-patterns in software development. Let's consolidate the key lessons:

Key Takeaways

•Exception swallowing creates invisible failures — Systems appear healthy while silently corrupting data, losing transactions, and frustrating users.
•Every exception must produce a signal — The four valid responses: log, rethrow, return error indicator, or self-heal with logging.
•Developer rationalizations are flawed — You cannot know at development time which exceptions will matter in production.
•Bad logging is nearly as bad as no logging — Include stack traces, context, correlation IDs, and appropriate log levels.
•Static analysis prevents swallowing — Configure tools to fail builds on empty catches. Treat violations as blocking bugs.
•Zero tolerance culture is essential — Make the team expectation clear: swallowed exceptions are never acceptable.

Coming Up Next

2 / 4