Error Handling Best Practices

Why This Matters

Error handling separates amateur code from production-ready software. In Programming Languages and Techniques III, you're being tested on your ability to design robust systems that anticipate failure, respond gracefully, and maintain stability under unexpected conditions. This isn't just about catching exceptions—it's about understanding control flow, resource management, abstraction layers, and defensive programming as interconnected principles.

When you encounter error handling questions on exams, you're really being asked to demonstrate mastery of program architecture. Can you identify where exceptions should be caught versus propagated? Do you understand why certain resources require guaranteed cleanup? Can you design custom exception hierarchies that communicate meaningful information? Don't just memorize syntax—know why each practice exists and when to apply it.

---

Exception Specificity and Type Hierarchies

Exception handling works best when you leverage the type system to communicate precise information about what went wrong. Generic catches obscure problems; specific catches enable targeted responses.

Use Specific Exception Types

• Specific exceptions provide semantic clarity—catching FileNotFoundException tells you exactly what failed, while catching Exception tells you almost nothing
• Type-specific handlers enable targeted recovery—you can retry a network timeout but should fail fast on an authentication error
• Debugging efficiency improves dramatically when stack traces point to meaningful exception types rather than generic wrappers

Avoid Catching Generic Exceptions

• Generic catches mask critical failures—a catch (Exception e) might silently swallow OutOfMemoryError or NullPointerException that indicate serious bugs
• Code clarity suffers when readers can't determine which error conditions the developer actually anticipated
• Anti-pattern alert: empty catch blocks (catch (Exception e) {}) are almost never acceptable in production code

---

Structured Exception Handling Mechanisms

The try-catch-finally construct provides a predictable control flow pattern for managing exceptional conditions. The key insight is separation of concerns: normal logic, error handling, and cleanup each have designated locations.

Implement Try-Catch Blocks

• Isolate error-prone operations within try blocks to clearly delineate where exceptions might originate
• Match catch blocks to expected exceptions—if you're reading a file, catch IOException, not Exception
• Control flow guarantee: code after a try-catch continues executing even if an exception occurred, unlike unhandled exceptions that terminate execution

Include Finally Blocks for Cleanup

• Guaranteed execution regardless of whether an exception was thrown, caught, or propagated—even if catch block throws
• Resource management essential for releasing file handles, database connections, network sockets, and locks
• Modern alternative: many languages offer try-with-resources (Java) or using statements (C#) that automate this pattern

---

Exception Propagation and Architecture

Where you handle exceptions matters as much as how you handle them. Exceptions should be caught at the level where meaningful action can be taken—not too early (losing context) or too late (crashing the system).

Throw Exceptions at the Appropriate Level

• Preserve context by throwing early—an exception thrown near the error source carries more diagnostic value than one thrown after several method calls
• Include meaningful messages that describe what operation failed and why, not just "Error occurred"
• Wrap lower-level exceptions when crossing abstraction boundaries to maintain encapsulation while preserving the original cause

Implement Proper Exception Propagation

• Let exceptions bubble up to layers that can make informed decisions—a data access method shouldn't decide how to display errors to users
• Centralized handling reduces duplication—handle logging and user notification in one place rather than scattered throughout the codebase
• Document thrown exceptions in method signatures (checked exceptions) or comments so callers know what to expect

---

Custom Exceptions and Domain Modeling

Standard exception types can't capture every error condition your application might encounter. Custom exceptions extend the type system to express domain-specific failure modes with precision.

Use Custom Exceptions for Domain-Specific Errors

• Encapsulate business logic failures—InsufficientFundsException communicates more than IllegalStateException
• Carry additional context through custom fields: error codes, affected entities, suggested remediation steps
• Maintain exception hierarchies by extending appropriate base classes—your PaymentException should probably extend RuntimeException or a domain-specific base

public class InsufficientFundsException extends RuntimeException {
    private final BigDecimal requested;
    private final BigDecimal available;
    
    // Constructor and getters...
}

---

Observability and Debugging Support

Exceptions that occur in production need to be discoverable and diagnosable. Logging transforms transient runtime events into permanent records for analysis.

Log Detailed Error Information

• Include contextual data: timestamps, user identifiers, request parameters, and the full stack trace
• Log at appropriate severity levels—ERROR for failures requiring attention, WARN for recoverable issues, DEBUG for development diagnostics
• Pattern detection becomes possible when logs capture enough detail to correlate related failures across time and system components

---

User Experience and Graceful Degradation

End users shouldn't experience the raw impact of system failures. Good error handling translates technical problems into understandable guidance while maintaining maximum functionality.

Handle Errors Gracefully in User Interfaces

• User-friendly messages explain what happened and what the user can do: "Unable to save your document. Please check your internet connection and try again."
• Hide technical details that confuse users and potentially expose security-sensitive information
• Fallback mechanisms maintain partial functionality—if live data is unavailable, show cached data with a warning

Implement Error Recovery Mechanisms

• Automatic retries with exponential backoff handle transient failures like network timeouts without user intervention
• Alternative workflows provide graceful degradation—if credit card processing fails, offer PayPal as backup
• Data integrity first: never sacrifice consistency for availability; failed transactions should roll back cleanly

---

Quick Reference Table

---

Self-Check Questions

1. You're writing a method that reads configuration from a file. Should you catch IOException inside the method or let it propagate? What factors influence this decision?

2. Compare catch (Exception e) with catch (FileNotFoundException e) followed by catch (IOException e)—what information is lost with the generic approach, and how does this affect debugging?

3. A database connection is opened in a try block. Where should the connection.close() call be placed, and why does this placement matter even if no exception occurs?

4. When would you create a custom exception class rather than using a standard library exception? Give an example of domain-specific information your custom exception might carry.

5. Compare error messages appropriate for log files versus user interfaces when a payment processing system fails. What should each contain, and what should each omit?