Try Catch

🔍 What Is It?

Exception Hierarchy:

Throwable
├── Error (JVM-level, do not catch)
│   ├── OutOfMemoryError
│   └── StackOverflowError
└── Exception
    ├── RuntimeException (unchecked — no throws declaration needed)
    │   ├── NullPointerException
    │   ├── IllegalArgumentException
    │   ├── IllegalStateException
    │   └── IndexOutOfBoundsException
    └── Checked Exceptions (must declare or handle)
        ├── IOException
        ├── SQLException
        └── ParseException

Checked vs Unchecked:

• →Checked — compiler forces you to handle or declare with throws. Represents recoverable conditions (file not found, network timeout).
• →Unchecked (RuntimeException) — compiler does not require handling. Represents programming errors (null pointer, illegal argument).

try-with-resources (Java 7+):

Automatically closes any AutoCloseable resource when the block exits, even if an exception occurs.

🎯 Why Do We Need It?

Exception handling is essential for:

• →Resilience — handle expected failures (network timeout, DB unavailable) gracefully
• →Resource cleanup — always close files, connections, streams (try-with-resources)
• →Error reporting — log the full stack trace for debugging
• →User experience — show meaningful error messages, not stack traces
• →Transaction management — rollback transactions on failure

Without exception handling, any unexpected condition crashes the entire application.

🏗️ What Happens in Real Projects?

In enterprise Spring Boot applications:

• →Service methods catch specific exceptions and translate them to domain exceptions
• →Controllers use @ExceptionHandler or @ControllerAdvice to translate exceptions to HTTP responses
• →Repository layer wraps DataAccessException into domain-specific exceptions
• →try-with-resources is used for every I/O operation
• →Global exception handlers log and return structured error responses

⚙️ How It Works

Exception Propagation:

1. Exception is thrown at the point of failure
2. JVM searches up the call stack for a matching catch block
3. First matching catch block executes
4. If no catch found, JVM prints stack trace and terminates the thread

finally block:

Runs after try and catch, regardless of outcome. Used for cleanup that must happen even if an exception occurs. Not needed for resource cleanup if using try-with-resources.

Exception chaining:

When catching one exception and throwing another, always include the original as the cause: throw new ServiceException("message", originalException). This preserves the full diagnostic chain.

💻 Example

Exception Handling in Enterprise Code — Production-quality exception handling patterns.

// try-with-resources — automatically closes resources
public String readFile(Path path) throws IOException {
    try (BufferedReader reader = Files.newBufferedReader(path)) {
        return reader.lines().collect(Collectors.joining("
"));
    }
    // reader.close() is called automatically, even if exception occurs
}

// Multiple resources — closed in reverse order
public void copyFile(Path source, Path dest) throws IOException {
    try (InputStream in = Files.newInputStream(source);
         OutputStream out = Files.newOutputStream(dest)) {
        in.transferTo(out);
    }
}

// Multi-catch (Java 7+) — same handler for multiple exception types
public UserDto getUser(String id) {
    try {
        return userRepository.findById(id)
            .map(this::toDto)
            .orElseThrow(() -> new UserNotFoundException(id));
    } catch (IllegalArgumentException | NumberFormatException e) {
        throw new BadRequestException("Invalid user ID format: " + id, e);
    } catch (DataAccessException e) {
        // Always chain the original exception for diagnostics
        throw new ServiceException("Database error fetching user: " + id, e);
    }
}

// finally — cleanup when try-with-resources is not applicable
public void processWithLock(String lockKey) {
    boolean locked = lockService.acquire(lockKey);
    if (!locked) throw new LockAcquisitionException(lockKey);
    
    try {
        doWork();
    } finally {
        lockService.release(lockKey);  // ALWAYS release the lock
    }
}

🤔 Common Confusions

🚨 Common Production Issues

✅ Best Practices

🏛️ Architect's Note

💬 Frequently Asked Questions

🎯 Key Takeaways

🔗 Related Topics

🎯 Practice this topic in interviews

↗ Where this topic fits