Best Practices & Anti-Patterns

#Best Practices 1–5: Catching and Wrapping

1. Catch the most specific exception

❌ Bad:

try {
    readFile();
} catch (Exception e) {
    logger.error("Error", e);
}

Why? It hides the real problem, makes recovery difficult, and can accidentally catch unrelated exceptions.

✅ Good:

try {
    readFile();
} catch (IOException e) {
    logger.error("Unable to read file", e);
}

Rule: specific exception first → general exception last.

2. Never swallow exceptions

❌ Bad:

try {
    saveUser();
} catch (Exception e) {
}

The exception disappears completely: no logs, no debugging information, silent failures.

✅ Good — log it, or propagate it:

catch (Exception e) {
    logger.error("User save failed", e);
}

3. Don't catch what you can't handle

Suppose repository.save(user); throws a SQLException. Should the repository handle it? Usually no.

4. Preserve the original cause

❌ Bad — the root cause is lost:

catch (IOException e) {
    throw new RuntimeException("Upload failed");
}

✅ Good:

catch (IOException e) {
    throw new FileUploadException("Upload failed", e);
}

This preserves the original exception, stack trace and debugging information.

5. Use meaningful custom exceptions

throw new RuntimeException("Error");                          // ❌ Bad
throw new UserNotFoundException("User ID 101 not found");     // ✅ Good

Meaningful exception names improve readability and API design.

#Best Practices 6–10: Flow, Resources and Logging

6. Never use exceptions for normal flow control

❌ Bad:

try {
    Integer.parseInt(input);
} catch (NumberFormatException e) {
    return false;
}

Exceptions are expensive. If validation can be done before the operation, prefer that approach.

7. Use try-with-resources

❌ Bad:

FileReader reader = new FileReader(file);
try {
    // Read
} finally {
    reader.close();
}

✅ Good:

try (FileReader reader = new FileReader(file)) {
    // Read
}

Cleaner and safer.

8. Don't log and rethrow everywhere

❌ Bad:

// Repository
catch (Exception e) {
    logger.error("Repository", e);
    throw e;
}

// Service
catch (Exception e) {
    logger.error("Service", e);
    throw e;
}

// Controller
catch (Exception e) {
    logger.error("Controller", e);
}

The same exception is logged three times.

✅ Good — log:

• Where the exception is finally handled, or
• Where you add meaningful business context.

9. Fail fast

Instead of allowing invalid data into createUser(name);:

if (name == null) {
    throw new IllegalArgumentException("Name cannot be null");
}

Early validation simplifies debugging.

10. Use checked exceptions carefully

Use checked exceptions when callers can recover — e.g. IOException, SQLException, InterruptedException.

Do not create checked exceptions for every business rule. Modern Spring Boot applications typically use unchecked exceptions for business validations.

#Best Practices 11–16: Scope, Messages and Handling

11. Don't catch Throwable

catch (Throwable t) {
}

This catches both Exception and Error — including OutOfMemoryError and StackOverflowError, which usually should not be handled by application code.

12. Don't catch Error

catch (Error e) {
}

Error indicates serious JVM-level failures.

13. Throw the most appropriate exception

throw new RuntimeException();                                  // ❌ Bad
throw new IllegalArgumentException();                          // ⚠️ Better
throw new InvalidOrderException("Order already shipped");      // ✅ Best

The more specific the exception, the easier it is to understand and handle.

14. Keep exception messages useful

throw new RuntimeException("Error");                                              // ❌ Bad
throw new RuntimeException("Unable to upload invoice: file size exceeds 10 MB");  // ✅ Good

A good message should explain:

• What happened
• Which resource or entity was involved (when appropriate)
• Enough context for troubleshooting without exposing sensitive information

15. Clean up resources properly

Always release files, streams, JDBC connections, PreparedStatements, ResultSets, locks and sockets. Prefer try-with-resources.

16. Use global exception handling

In Spring Boot, use @ControllerAdvice instead of a try { } catch { } in every controller. This keeps controllers focused on business logic.

#Logging Best Practices

❌ Bad — only the message is logged:

logger.error(e.getMessage());

✅ Good:

logger.error("File upload failed", e);

Now you get the message, stack trace, root cause and suppressed exceptions (if any).