Error handling is often treated as an afterthought in programming. Many developers focus on the happy path\u2014the expected flow of execution when everything works perfectly. But in the real world, things go wrong. APIs fail, networks drop, users input unexpected data, and systems run out of resources. A robust error handling strategy is not just about catching exceptions; it’s about anticipating and gracefully managing the unexpected.<\/p>\n
In this comprehensive guide, we’ll explore why most error handling strategies fall short when it comes to edge cases, and how you can build more resilient applications by addressing these blind spots.<\/p>\n
Edge cases are situations that occur at the extremes of operating parameters. In the context of error handling, these are the rare, unexpected scenarios that your application might encounter. While they may be infrequent, failing to handle them properly can lead to catastrophic failures, data corruption, or security vulnerabilities.<\/p>\n
Resource Exhaustion:<\/strong> Applications can run out of memory, disk space, file handles, or other resources. Many error handling strategies fail to account for these scenarios.<\/p>\n Cascading Failures:<\/strong> When one component fails, it can trigger failures in dependent components. A robust error handling strategy should prevent these cascading effects.<\/p>\n Timing and Race Conditions:<\/strong> Concurrent operations can lead to unexpected states and errors that are difficult to reproduce and debug.<\/p>\n Partial Failures:<\/strong> Sometimes operations fail after partially completing, leaving the system in an inconsistent state.<\/p>\n Silent Failures:<\/strong> Some errors occur without raising exceptions or returning error codes, making them particularly insidious.<\/p>\n External System Failures:<\/strong> Dependencies on third-party services or APIs introduce additional failure modes that are often overlooked.<\/p>\n Failing to handle edge cases properly can result in:<\/p>\n A study by Gartner found that the average cost of IT downtime is $5,600 per minute, which translates to over $300,000 per hour. Many of these incidents could have been prevented with more thorough error handling.<\/p>\n Even when developers attempt to implement error handling, they often make critical mistakes that leave their applications vulnerable. Let’s examine some of the most common pitfalls.<\/p>\n One of the most prevalent mistakes is using overly broad exception handlers:<\/p>\n This approach fails to distinguish between different types of errors, each of which might require specific handling. It also masks bugs that should cause the application to fail fast and visibly.<\/p>\n Even worse than catching all exceptions is catching them and doing nothing:<\/p>\n This pattern hides errors, making debugging nearly impossible and potentially leading to silent failures that corrupt data or create security vulnerabilities.<\/p>\n Logging errors without sufficient context limits your ability to diagnose and fix issues:<\/p>\n Effective error logs should include the exception stack trace, relevant context data, and a clear description of what the code was trying to do when the error occurred.<\/p>\n Failing to properly release resources in error scenarios can lead to resource leaks:<\/p>\n Modern languages provide better constructs for resource management (like Java’s try-with-resources or Python’s context managers), but they’re often underutilized.<\/p>\n Some developers avoid exceptions by returning null or special values to indicate errors:<\/p>\n This approach pushes error handling responsibility to the caller, who might not check for null returns, leading to NullPointerExceptions further down the call stack.<\/p>\n When different parts of the application handle errors differently, it becomes difficult to reason about error flows and ensure proper recovery:<\/p>\n This inconsistency makes the codebase harder to maintain and can lead to unexpected behavior when modules interact.<\/p>\n A robust error handling strategy requires a systematic approach that considers all potential failure modes. Here’s a framework for developing such a strategy:<\/p>\n Not all errors are created equal. Categorizing errors helps determine the appropriate response:<\/p>\n For each category of error, define clear policies:<\/p>\n Circuit breakers prevent cascading failures by automatically detecting when a dependency is failing and stopping requests to it:<\/p>\n This pattern is especially valuable for microservices architectures where dependencies on external systems are common.<\/p>\n Every external call should have a timeout to prevent hanging operations:<\/p>\n Design your application to function at reduced capacity when components fail:<\/p>\n Bulkheads isolate components to prevent failures in one area from affecting others:<\/p>\n This approach ensures that, for example, a flood of notifications won’t prevent order processing from continuing.<\/p>\n Different programming languages provide different mechanisms for error handling. Understanding these language-specific features is crucial for implementing effective error handling.<\/p>\n Java uses a combination of checked and unchecked exceptions:<\/p>\n Python uses a try\/except\/finally mechanism and context managers:<\/p>\n JavaScript traditionally uses try\/catch blocks but has evolved to include Promises and async\/await:<\/p>\n Go uses a different approach, returning errors as values rather than throwing exceptions:<\/p>\n Identifying and testing edge cases is essential for robust error handling. Here are techniques to ensure your error handling strategy is comprehensive:<\/p>\n Chaos engineering involves deliberately introducing failures to test system resilience:<\/p>\n Systematically inject faults at various points in your application:<\/p>\n Generate a wide range of inputs to discover edge cases:<\/p>\n Test how your error handling performs under high load:<\/p>\n Test at the boundaries of valid inputs and resource limits:<\/p>\n Even with the best testing, errors will occur in production. A comprehensive error handling strategy includes monitoring and responding to these errors.<\/p>\n Structured logging provides context for debugging:<\/p>\n Set up monitoring systems to detect error patterns:<\/p>\n Health checks help detect and isolate failing components:<\/p>\n Feature flags allow quick disabling of problematic features:<\/p>\n Learning from real-world failures can help improve your error handling strategy. Here are some notable examples:<\/p>\n In February 2017, a typo in a command during routine server maintenance took down a significant portion of Amazon S3 for over four hours. The system didn't have adequate safeguards against removing too many servers at once, and the restart process was slower than expected due to the system's scale.<\/p>\n Lessons Learned:<\/strong><\/p>\n Knight Capital lost $440 million in 45 minutes due to a software error. They deployed new code to only some of their servers, creating inconsistent behavior. When an error occurred, the system continued to execute erroneous trades rather than shutting down.<\/p>\n Lessons Learned:<\/strong><\/p>\n A buffer overflow in Cloudflare's edge servers caused sensitive data to leak into cached web pages. The error occurred in an HTML parser designed to modify web pages for optimization.<\/p>\n Lessons Learned:<\/strong><\/p>\n Based on everything we've covered, here are the key best practices for a comprehensive error handling strategy:<\/p>\n Define a consistent approach to error handling across your codebase:<\/p>\n Detect and report errors as early as possible:<\/p>\n Error messages should be actionable and informative:<\/p>\n Always clean up resources, even when errors occur:<\/p>\n Include relevant context in error logs:<\/p>\n Implement exponential backoff for retrying operations:<\/p>\n Error handling is not just about catching<\/p>\n","protected":false},"excerpt":{"rendered":" Error handling is often treated as an afterthought in programming. Many developers focus on the happy path\u2014the expected flow of…<\/p>\n","protected":false},"author":1,"featured_media":7523,"comment_status":"","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[23],"tags":[],"class_list":["post-7524","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-problem-solving"],"_links":{"self":[{"href":"https:\/\/algocademy.com\/blog\/wp-json\/wp\/v2\/posts\/7524"}],"collection":[{"href":"https:\/\/algocademy.com\/blog\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/algocademy.com\/blog\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/algocademy.com\/blog\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/algocademy.com\/blog\/wp-json\/wp\/v2\/comments?post=7524"}],"version-history":[{"count":0,"href":"https:\/\/algocademy.com\/blog\/wp-json\/wp\/v2\/posts\/7524\/revisions"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/algocademy.com\/blog\/wp-json\/wp\/v2\/media\/7523"}],"wp:attachment":[{"href":"https:\/\/algocademy.com\/blog\/wp-json\/wp\/v2\/media?parent=7524"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/algocademy.com\/blog\/wp-json\/wp\/v2\/categories?post=7524"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/algocademy.com\/blog\/wp-json\/wp\/v2\/tags?post=7524"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}The Cost of Ignoring Edge Cases<\/h3>\n
\n
Common Mistakes in Error Handling Strategies<\/h2>\n
Catching All Exceptions<\/h3>\n
try {\n \/\/ Code that might throw multiple types of exceptions\n} catch (Exception e) {\n \/\/ Generic handling for all exceptions\n log.error("An error occurred", e);\n}<\/code><\/pre>\nSwallowing Exceptions<\/h3>\n
try {\n riskyOperation();\n} catch (Exception e) {\n \/\/ Empty catch block - exception is swallowed\n}<\/code><\/pre>\nInadequate Logging<\/h3>\n
try {\n processUserData(userData);\n} catch (Exception e) {\n log.error("Error processing user data"); \/\/ No exception details or user context\n}<\/code><\/pre>\nIgnoring Resource Cleanup<\/h3>\n
FileOutputStream fos = null;\ntry {\n fos = new FileOutputStream("file.txt");\n \/\/ Write to file\n} catch (IOException e) {\n log.error("Failed to write to file", e);\n}\n\/\/ Missing finally block to close fos<\/code><\/pre>\nReturning Null Instead of Throwing Exceptions<\/h3>\n
public User findUserById(String id) {\n if (id == null) {\n return null; \/\/ Returning null instead of throwing IllegalArgumentException\n }\n \/\/ Normal processing\n}<\/code><\/pre>\nInconsistent Error Handling Across the Codebase<\/h3>\n
\/\/ Module A\ntry {\n \/\/ Operation\n} catch (Exception e) {\n throw new ServiceException("Operation failed", e);\n}\n\n\/\/ Module B\ntry {\n \/\/ Similar operation\n} catch (Exception e) {\n return ErrorResult.of(e.getMessage());\n}<\/code><\/pre>\nA Comprehensive Approach to Error Handling<\/h2>\n
Categorize Errors<\/h3>\n
\n
Define Error Handling Policies<\/h3>\n
\n
Implement Circuit Breakers<\/h3>\n
CircuitBreaker circuitBreaker = CircuitBreakerFactory.create(\n "api-service",\n 3, \/\/ Failure threshold\n 1000, \/\/ Reset timeout in milliseconds\n TimeUnit.MILLISECONDS\n);\n\npublic Response callExternalService() {\n return circuitBreaker.execute(() -> {\n \/\/ Call to external service\n return apiClient.makeRequest();\n }, (e) -> {\n \/\/ Fallback when circuit is open or call fails\n return Response.fallback();\n });\n}<\/code><\/pre>\nUse Timeouts<\/h3>\n
CompletableFuture<Result> future = CompletableFuture.supplyAsync(() -> {\n return slowOperation();\n});\n\ntry {\n Result result = future.get(5, TimeUnit.SECONDS);\n \/\/ Process result\n} catch (TimeoutException e) {\n \/\/ Handle timeout\n log.warn("Operation timed out after 5 seconds");\n future.cancel(true); \/\/ Attempt to cancel the operation\n return fallbackResult();\n}<\/code><\/pre>\nImplement Graceful Degradation<\/h3>\n
public SearchResults search(String query) {\n SearchResults results = new SearchResults();\n \n \/\/ Try to get results from primary search engine\n try {\n results.addAll(primarySearch.search(query));\n } catch (SearchException e) {\n log.warn("Primary search failed, falling back to backup", e);\n \/\/ Fall back to backup search engine\n try {\n results.addAll(backupSearch.search(query));\n } catch (SearchException e2) {\n log.error("Backup search also failed", e2);\n \/\/ Return empty results rather than failing completely\n }\n }\n \n \/\/ Try to add recommendations if available\n try {\n results.setRecommendations(recommendationService.getRecommendations(query));\n } catch (Exception e) {\n \/\/ Non-critical feature can fail without affecting core functionality\n log.info("Recommendations unavailable", e);\n }\n \n return results;\n}<\/code><\/pre>\nUse Bulkheads<\/h3>\n
\/\/ Define separate thread pools for different components\nExecutorService ordersPool = Executors.newFixedThreadPool(10);\nExecutorService inventoryPool = Executors.newFixedThreadPool(5);\nExecutorService notificationsPool = Executors.newFixedThreadPool(3);\n\n\/\/ Use the appropriate pool for each type of operation\npublic void processOrder(Order order) {\n CompletableFuture.supplyAsync(() -> {\n return orderService.process(order);\n }, ordersPool).thenAcceptAsync(result -> {\n inventoryService.update(result);\n }, inventoryPool).thenAcceptAsync(result -> {\n notificationService.notify(result);\n }, notificationsPool);\n}<\/code><\/pre>\nLanguage-Specific Error Handling Techniques<\/h2>\n
Java<\/h3>\n
\/\/ Using try-with-resources for automatic resource cleanup\ntry (Connection conn = dataSource.getConnection();\n PreparedStatement stmt = conn.prepareStatement("SELECT * FROM users WHERE id = ?")) {\n stmt.setString(1, userId);\n try (ResultSet rs = stmt.executeQuery()) {\n if (rs.next()) {\n return mapToUser(rs);\n } else {\n throw new UserNotFoundException("User not found with ID: " + userId);\n }\n }\n} catch (SQLException e) {\n throw new DatabaseException("Database error while fetching user", e);\n} catch (UserNotFoundException e) {\n \/\/ Rethrow application-specific exceptions\n throw e;\n} catch (Exception e) {\n \/\/ Unexpected exceptions\n throw new ServiceException("Unexpected error fetching user", e);\n}<\/code><\/pre>\nPython<\/h3>\n
def get_user(user_id):\n try:\n with db.session() as session:\n user = session.query(User).filter(User.id == user_id).first()\n if not user:\n raise UserNotFoundError(f"User not found with ID: {user_id}")\n return user\n except SQLAlchemyError as e:\n logger.error(f"Database error: {str(e)}")\n raise DatabaseError("Database error while fetching user") from e\n except UserNotFoundError:\n # Log and rethrow\n logger.info(f"User not found: {user_id}")\n raise\n except Exception as e:\n logger.exception("Unexpected error fetching user")\n raise ServiceError("Unexpected error fetching user") from e<\/code><\/pre>\nJavaScript\/TypeScript<\/h3>\n
async function getUser(userId) {\n try {\n const response = await fetch(`\/api\/users\/${userId}`);\n \n if (!response.ok) {\n if (response.status === 404) {\n throw new UserNotFoundError(`User not found with ID: ${userId}`);\n }\n throw new ApiError(`API error: ${response.status}`);\n }\n \n const userData = await response.json();\n return new User(userData);\n } catch (error) {\n if (error instanceof UserNotFoundError) {\n \/\/ Handle specific error\n console.log(error.message);\n throw error;\n } else if (error instanceof ApiError) {\n \/\/ Handle API errors\n console.error('API Error:', error);\n throw new ServiceError('Service temporarily unavailable');\n } else if (error instanceof TypeError) {\n \/\/ Network errors often manifest as TypeErrors\n console.error('Network Error:', error);\n throw new ConnectionError('Unable to connect to the server');\n } else {\n \/\/ Unexpected errors\n console.error('Unexpected Error:', error);\n throw new Error('An unexpected error occurred');\n }\n }\n}<\/code><\/pre>\nGo<\/h3>\n
func GetUser(id string) (*User, error) {\n if id == \"\" {\n return nil, errors.New(\"user ID cannot be empty\")\n }\n \n db, err := sql.Open(\"postgres\", connectionString)\n if err != nil {\n return nil, fmt.Errorf(\"failed to connect to database: %w\", err)\n }\n defer db.Close()\n \n var user User\n err = db.QueryRow(\"SELECT id, name, email FROM users WHERE id = $1\", id).Scan(&user.ID, &user.Name, &user.Email)\n if err != nil {\n if err == sql.ErrNoRows {\n return nil, &UserNotFoundError{ID: id}\n }\n return nil, fmt.Errorf(\"database error: %w\", err)\n }\n \n return &user, nil\n}<\/code><\/pre>\nTesting for Edge Cases<\/h2>\n
Chaos Engineering<\/h3>\n
@Test\npublic void testDatabaseFailure() {\n \/\/ Simulate database connection failure\n when(dataSource.getConnection()).thenThrow(new SQLException(\"Connection refused\"));\n \n \/\/ Verify the service handles the failure gracefully\n assertThatThrownBy(() -> userService.getUser(\"123\"))\n .isInstanceOf(ServiceUnavailableException.class)\n .hasMessageContaining(\"Database unavailable\");\n \n \/\/ Verify proper logging\n verify(logger).error(contains(\"Database connection failed\"), any(SQLException.class));\n}<\/code><\/pre>\nFault Injection<\/h3>\n
public class FaultInjectingHttpClient implements HttpClient {\n private final HttpClient delegate;\n private final double failureRate;\n private final Random random = new Random();\n \n @Override\n public HttpResponse send(HttpRequest request) throws IOException {\n if (random.nextDouble() < failureRate) {\n throw new IOException(\"Simulated network failure\");\n }\n return delegate.send(request);\n }\n}<\/code><\/pre>\nProperty-Based Testing<\/h3>\n
@Property\nvoid handlesAllInputTypes(\n @ForAll @AlphaChars String alphabeticInput,\n @ForAll @NumericChars String numericInput,\n @ForAll @StringLength(min = 0, max = 1000) String varyingLengthInput,\n @ForAll @Chars(from = 0, to = 127) String asciiInput\n) {\n \/\/ Test that the function doesn't throw unexpected exceptions\n assertDoesNotThrow(() -> processor.process(alphabeticInput));\n assertDoesNotThrow(() -> processor.process(numericInput));\n assertDoesNotThrow(() -> processor.process(varyingLengthInput));\n assertDoesNotThrow(() -> processor.process(asciiInput));\n}<\/code><\/pre>\nLoad and Stress Testing<\/h3>\n
@Test\npublic void testConcurrentRequests() throws InterruptedException {\n int numThreads = 100;\n CountDownLatch latch = new CountDownLatch(numThreads);\n AtomicInteger successCount = new AtomicInteger(0);\n AtomicInteger errorCount = new AtomicInteger(0);\n \n for (int i = 0; i < numThreads; i++) {\n new Thread(() -> {\n try {\n service.processRequest();\n successCount.incrementAndGet();\n } catch (Exception e) {\n errorCount.incrementAndGet();\n } finally {\n latch.countDown();\n }\n }).start();\n }\n \n latch.await(30, TimeUnit.SECONDS);\n System.out.println(\"Successful requests: \" + successCount.get());\n System.out.println(\"Failed requests: \" + errorCount.get());\n \n \/\/ Even under load, we should have a reasonable success rate\n assertThat(successCount.get()).isGreaterThan(numThreads * 0.8);\n}<\/code><\/pre>\nBoundary Testing<\/h3>\n
@Test\npublic void testMaximumInputSize() {\n String largeInput = \"A\".repeat(MAX_INPUT_SIZE);\n String tooLargeInput = \"A\".repeat(MAX_INPUT_SIZE + 1);\n \n \/\/ Should handle maximum valid size\n assertDoesNotThrow(() -> validator.validate(largeInput));\n \n \/\/ Should reject input that's too large\n assertThatThrownBy(() -> validator.validate(tooLargeInput))\n .isInstanceOf(InvalidInputException.class)\n .hasMessageContaining(\"exceeds maximum size\");\n}<\/code><\/pre>\nMonitoring and Handling Errors in Production<\/h2>\n
Implementing Proper Logging<\/h3>\n
try {\n processPayment(order);\n} catch (PaymentException e) {\n log.error(\"Payment processing failed\", Map.of(\n \"orderId\", order.getId(),\n \"amount\", order.getAmount(),\n \"customerId\", order.getCustomerId(),\n \"paymentMethod\", order.getPaymentMethod(),\n \"errorCode\", e.getErrorCode()\n ), e);\n \n notifyPaymentTeam(e, order);\n return PaymentResult.failure(e.getErrorCode());\n}<\/code><\/pre>\nReal-time Monitoring and Alerting<\/h3>\n
\/\/ Define an alert rule in Prometheus\nalert: HighErrorRate\nexpr: sum(rate(http_requests_total{status=~\"5..\"}[5m])) \/ sum(rate(http_requests_total[5m])) > 0.05\nfor: 1m\nlabels:\n severity: critical\nannotations:\n summary: High HTTP error rate\n description: More than 5% of requests are failing with 5xx errors for the past minute.<\/code><\/pre>\nImplementing Health Checks<\/h3>\n
@GetMapping(\"\/health\")\npublic ResponseEntity<HealthStatus> healthCheck() {\n HealthStatus status = new HealthStatus();\n \n \/\/ Check database connectivity\n try {\n boolean dbHealthy = databaseService.ping();\n status.addComponent(\"database\", dbHealthy ? \"UP\" : \"DOWN\");\n } catch (Exception e) {\n status.addComponent(\"database\", \"DOWN\");\n status.addError(\"database\", e.getMessage());\n }\n \n \/\/ Check cache connectivity\n try {\n boolean cacheHealthy = cacheService.ping();\n status.addComponent(\"cache\", cacheHealthy ? \"UP\" : \"DOWN\");\n } catch (Exception e) {\n status.addComponent(\"cache\", \"DOWN\");\n status.addError(\"cache\", e.getMessage());\n }\n \n \/\/ Overall status is UP only if all critical components are UP\n boolean isHealthy = status.isCriticalComponentsHealthy();\n \n return ResponseEntity\n .status(isHealthy ? HttpStatus.OK : HttpStatus.SERVICE_UNAVAILABLE)\n .body(status);\n}<\/code><\/pre>\nImplementing Feature Flags<\/h3>\n
public SearchResult search(String query) {\n SearchResult result = new SearchResult();\n \n \/\/ Add basic search results\n result.addItems(basicSearch(query));\n \n \/\/ Only include advanced features if enabled\n if (featureFlags.isEnabled(\"advanced-search\")) {\n try {\n result.addItems(advancedSearch(query));\n } catch (Exception e) {\n log.error(\"Advanced search failed\", e);\n \/\/ Disable the feature if it fails repeatedly\n if (errorTracker.shouldDisableFeature(\"advanced-search\", e)) {\n featureFlags.disable(\"advanced-search\");\n log.warn(\"Advanced search feature automatically disabled due to errors\");\n }\n }\n }\n \n return result;\n}<\/code><\/pre>\nCase Studies: When Error Handling Goes Wrong<\/h2>\n
Amazon S3 Outage (2017)<\/h3>\n
\n
Knight Capital Group (2012)<\/h3>\n
\n
Cloudflare Memory Leak (2017)<\/h3>\n
\n
Best Practices for Robust Error Handling<\/h2>\n
Design for Failure<\/h3>\n
\n
Be Specific About Exceptions<\/h3>\n
\/\/ Bad\ntry {\n processData(input);\n} catch (Exception e) {\n log.error(\"Error\", e);\n}\n\n\/\/ Good\ntry {\n processData(input);\n} catch (InvalidInputException e) {\n log.warn(\"Invalid input: {}\", e.getMessage());\n return Result.error(\"Invalid input format\");\n} catch (DatabaseException e) {\n log.error(\"Database error while processing data\", e);\n return Result.error(\"Service temporarily unavailable\");\n} catch (Exception e) {\n log.error(\"Unexpected error processing data\", e);\n return Result.error(\"An unexpected error occurred\");\n}<\/code><\/pre>\nUse a Consistent Error Model<\/h3>\n
public class Result<T> {\n private final boolean success;\n private final T data;\n private final ErrorInfo error;\n \n private Result(boolean success, T data, ErrorInfo error) {\n this.success = success;\n this.data = data;\n this.error = error;\n }\n \n public static <T> Result<T> success(T data) {\n return new Result<>(true, data, null);\n }\n \n public static <T> Result<T> error(String message) {\n return new Result<>(false, null, new ErrorInfo(message));\n }\n \n public static <T> Result<T> error(String message, String code) {\n return new Result<>(false, null, new ErrorInfo(message, code));\n }\n \n \/\/ Additional methods...\n}<\/code><\/pre>\nFail Fast<\/h3>\n
public void processOrder(Order order) {\n \/\/ Validate inputs immediately\n if (order == null) {\n throw new IllegalArgumentException(\"Order cannot be null\");\n }\n \n if (order.getItems() == null || order.getItems().isEmpty()) {\n throw new InvalidOrderException(\"Order must contain at least one item\");\n }\n \n if (order.getCustomerId() == null) {\n throw new InvalidOrderException(\"Order must have a customer ID\");\n }\n \n \/\/ Proceed with processing\n \/\/ ...\n}<\/code><\/pre>\nProvide Meaningful Error Messages<\/h3>\n
\/\/ Bad\nthrow new Exception(\"Error\");\n\n\/\/ Good\nthrow new ConfigurationException(\n \"Database connection failed: Unable to connect to MySQL server at db.example.com:3306. \" +\n \"Please check that the database server is running and network connectivity is available. \" +\n \"Error details: Connection refused (Connection refused)\"\n);<\/code><\/pre>\nImplement Proper Resource Management<\/h3>\n
\/\/ Java example with try-with-resources\ntry (\n Connection conn = dataSource.getConnection();\n PreparedStatement stmt = conn.prepareStatement(SQL_QUERY);\n ResultSet rs = stmt.executeQuery()\n) {\n \/\/ Process results\n} catch (SQLException e) {\n \/\/ Handle exception\n}<\/code><\/pre>\nLog Errors with Context<\/h3>\n
try {\n processOrder(order);\n} catch (Exception e) {\n log.error(\"Failed to process order: {}, customer: {}, items: {}\", \n order.getId(),\n order.getCustomerId(),\n order.getItems().size(),\n e);\n}<\/code><\/pre>\nUse Retry with Backoff for Transient Failures<\/h3>\n
public <T> T executeWithRetry(Supplier<T> operation) {\n int maxRetries = 3;\n int retryCount = 0;\n int waitTimeMs = 1000; \/\/ Start with 1 second\n \n while (true) {\n try {\n return operation.get();\n } catch (Exception e) {\n retryCount++;\n \n if (isTransientException(e) && retryCount <= maxRetries) {\n log.warn(\"Operation failed with transient error, retrying ({}\/{}): {}\", \n retryCount, maxRetries, e.getMessage());\n \n try {\n Thread.sleep(waitTimeMs);\n \/\/ Exponential backoff\n waitTimeMs *= 2;\n } catch (InterruptedException ie) {\n Thread.currentThread().interrupt();\n throw new RuntimeException(\"Retry interrupted\", ie);\n }\n } else {\n log.error(\"Operation failed permanently after {} tries\", retryCount, e);\n throw e;\n }\n }\n }\n}<\/code><\/pre>\nConclusion<\/h2>\n