15+ Java Exceptions Every Developer Must Know [2025]

Every Java developer has been there: you’re coding along and suddenly your application crashes with an exception. The stack trace looks intimidating, but understanding these exceptions is crucial for writing robust applications.

This guide covers the most common Java exceptions you’ll encounter, what causes them, and how to handle them effectively. We’ll look at both runtime and checked exceptions, with practical examples and best practices for each.

Understanding Java Exceptions

Java exceptions fall into two main categories:

• Checked exceptions: Must be handled or declared at compile time (like IOException)
• Runtime exceptions: Can occur during execution without compile-time handling requirements (like NullPointerException)

Checked exceptions represent recoverable conditions that a well-written application should anticipate and handle. Runtime exceptions usually indicate programming errors or unexpected conditions.

Common Runtime Exceptions

1. NullPointerException

The NullPointerException is probably the most encountered exception in Java. It occurs when your code attempts to use a reference that points to no location in memory (null) as though it’s pointing to an object.

This typically happens when you forget to initialize an object or when a method returns null unexpectedly.

// Example that causes NullPointerException
String name = null;
int length = name.length(); // Throws java.lang.NullPointerException

// Modern Java (14+) provides helpful messages:
// java.lang.NullPointerException: Cannot invoke "String.length()" because "name" is null

Common causes:

• Forgetting to initialize objects
• Methods returning null unexpectedly
• Accessing uninitialized collections or arrays

Prevention strategies:

// Use Optional for methods that might return null
public Optional<User> findUserById(String id) {
    User user = database.getUser(id);
    return Optional.ofNullable(user);
}

// Null checks before operations
if (name != null && !name.isEmpty()) {
    int length = name.length();
}

// Use defensive programming
public void processUser(User user) {
    Objects.requireNonNull(user, "User cannot be null");
    // Safe to use user here
}

2. ArrayIndexOutOfBoundsException

This exception occurs when you try to access an array element with an invalid index—either negative or greater than or equal to the array’s length.

Remember that arrays are zero-indexed, so an array with 3 elements has valid indices 0, 1, and 2.

int[] numbers = {1, 2, 3};
int value = numbers[5]; // Throws java.lang.ArrayIndexOutOfBoundsException: Index 5 out of bounds for length 3

Prevention:

// Always check array bounds
if (index >= 0 && index < numbers.length) {
    int value = numbers[index];
}

// Use enhanced for loops when possible
for (int number : numbers) {
    System.out.println(number);
}

3. ClassCastException

The ClassCastException is thrown when you attempt to cast an object to a class of which it is not an instance.

This commonly occurs when working with raw collections or when downcasting objects incorrectly.

Object obj = "Hello World";
Integer number = (Integer) obj; // Throws java.lang.ClassCastException

Safe casting:

// Use instanceof before casting
if (obj instanceof Integer) {
    Integer number = (Integer) obj;
    // Safe to use number
}

// Pattern matching (Java 16+)
if (obj instanceof Integer number) {
    // Use number directly
    System.out.println(number * 2);
}

4. IllegalArgumentException

This exception indicates that a method has been passed an illegal or inappropriate argument. It’s commonly used in defensive programming to validate method parameters.

public void setAge(int age) {
    if (age < 0 || age > 150) {
        throw new IllegalArgumentException("Age must be between 0 and 150, got: " + age);
    }
    this.age = age;
}

5. IllegalStateException

The IllegalStateException signals that a method has been invoked at an illegal or inappropriate state. This typically occurs when an object is not in the correct state for the requested operation.

public class OrderProcessor {
    private boolean initialized = false;
    
    public void processOrder(Order order) {
        if (!initialized) {
            throw new IllegalStateException("OrderProcessor not initialized");
        }
        // Process order
    }
}

6. NumberFormatException

This exception occurs when attempting to convert a string to a numeric type, but the string doesn’t have the appropriate format. It’s a subclass of IllegalArgumentException.

// Throws java.lang.NumberFormatException: For input string: "abc"
int number = Integer.parseInt("abc");

// Safe parsing
try {
    int number = Integer.parseInt(input);
} catch (NumberFormatException e) {
    // Handle invalid input
    System.err.println("Invalid number format: " + input);
}

Common Checked Exceptions

7. IOException

The IOException is thrown when an I/O operation fails or is interrupted. It’s one of the most common checked exceptions you’ll encounter when working with files, network connections, or other external resources.

// Reading files requires IOException handling
try {
    String content = Files.readString(Paths.get("config.txt"));
} catch (IOException e) {
    logger.error("Failed to read configuration file", e);
    // Provide default configuration or fail gracefully
}

Common IOException subtypes:

• FileNotFoundException - Specific file cannot be found
• SocketTimeoutException - Network operation timed out
• EOFException - Unexpected end of file reached

8. ClassNotFoundException

This checked exception occurs when the Java Virtual Machine tries to load a class through its string name but cannot find the definition for the class.

This typically happens during reflection operations when the specified class is not available on the classpath.

try {
    Class<?> clazz = Class.forName("com.example.MissingClass");
} catch (ClassNotFoundException e) {
    logger.error("Class not found on classpath", e);
    // Handle missing dependency
}

9. SQLException

Ah, database problems. Could be anything: connection died, syntax error in your query, table doesn’t exist, or the database is just having a bad day.

try (Connection conn = dataSource.getConnection();
     PreparedStatement stmt = conn.prepareStatement("SELECT * FROM users WHERE id = ?")) {
    
    stmt.setLong(1, userId);
    ResultSet rs = stmt.executeQuery();
    // Process results
    
} catch (SQLException e) {
    logger.error("Database operation failed for user: " + userId, e);
    throw new UserServiceException("Unable to retrieve user data", e);
}

Additional Common Exceptions

10. ConcurrentModificationException

This exception occurs when a collection is modified while being iterated over by another thread or iterator. Java’s fail-fast iterators detect concurrent modifications and throw this exception to prevent unpredictable behavior.

List<String> list = new ArrayList<>(Arrays.asList("a", "b", "c"));

// This throws ConcurrentModificationException
for (String item : list) {
    if ("b".equals(item)) {
        list.remove(item); // Don't do this!
    }
}

// Correct approach
Iterator<String> iterator = list.iterator();
while (iterator.hasNext()) {
    String item = iterator.next();
    if ("b".equals(item)) {
        iterator.remove(); // Safe removal
    }
}

11. StackOverflowError

While technically an Error rather than an Exception, StackOverflowError is commonly encountered during development. It occurs when the call stack exceeds its limit, typically due to uncontrolled recursion or excessively deep method calls.

// Causes StackOverflowError
public int factorial(int n) {
    return n * factorial(n - 1); // Missing base case!
}

// Correct implementation
public int factorial(int n) {
    if (n <= 1) return 1; // Base case
    return n * factorial(n - 1);
}

12. OutOfMemoryError

OutOfMemoryError occurs when the JVM cannot allocate an object because it is out of memory and no more memory can be made available by the garbage collector. This typically indicates memory leaks, insufficient heap size, or inefficient memory usage patterns.

// Common causes and solutions
// 1. Memory leaks - use profilers to identify
// 2. Insufficient heap size - increase with -Xmx flag
// 3. Creating too many objects - optimize algorithms

// Example: Avoid creating unnecessary objects in loops
// Bad
for (int i = 0; i < 1000000; i++) {
    String str = new String("Hello"); // Creates new object each time
}

// Better
String str = "Hello"; // Reuse string literal
for (int i = 0; i < 1000000; i++) {
    // Use str
}

Exception Handling Best Practices

1. Be Specific with Exception Types

Catching generic Exception masks the root cause and makes debugging harder. Instead, catch specific exception types to handle different error scenarios appropriately.

// Bad: Catches everything
try {
    processUserData(userData);
} catch (Exception e) {
    // Too generic
}

// Good: Handle specific exceptions differently
try {
    processUserData(userData);
} catch (ValidationException e) {
    return ResponseEntity.badRequest().body("Invalid user data: " + e.getMessage());
} catch (DataAccessException e) {
    logger.error("Database error processing user", e);
    return ResponseEntity.status(500).body("Internal server error");
}

2. Provide Meaningful Error Messages

Generic error messages frustrate developers and users. Include relevant context, expected values, and actionable information in your exception messages.

// Bad: Generic message
throw new IllegalArgumentException("Invalid input");

// Good: Specific and actionable
throw new IllegalArgumentException("Email address cannot be null or empty. Received: " + email);

3. Use Try-With-Resources for Resource Management

Resources like files, database connections, and network sockets must be properly closed to prevent memory leaks. Try-with-resources automatically handles cleanup, even when exceptions occur.

// Automatically closes resources
try (FileInputStream fis = new FileInputStream("data.txt");
     BufferedReader reader = new BufferedReader(new InputStreamReader(fis))) {
    
    return reader.lines().collect(Collectors.toList());
    
} catch (IOException e) {
    logger.error("Error reading file", e);
    throw new DataProcessingException("Unable to read input file", e);
}

4. Don’t Swallow Exceptions

Silent failures are debugging nightmares. Always log exceptions or rethrow them with additional context. If you must ignore an exception, document why with a clear comment.

// Bad: Silent failure
try {
    criticalOperation();
} catch (Exception e) {
    // TODO: Handle this (famous last words)
}

// Good: At least log it
try {
    criticalOperation();
} catch (Exception e) {
    logger.error("Critical operation failed", e);
    // Decide: rethrow, return error code, or use default behavior
    throw new SystemException("Critical operation failed", e);
}

Debugging Exception-Heavy Applications

When working with applications that throw many exceptions, consider these debugging strategies:

1. Structured Logging

// Include relevant context in logs
logger.error("Failed to process order", 
    Map.of(
        "orderId", order.getId(),
        "userId", order.getUserId(), 
        "amount", order.getAmount(),
        "exception", e.getClass().getSimpleName()
    ), 
    e);

3. Exception Analysis

Use tools like Debugly to format and analyze stack traces for better readability. While debugging, focus on identifying:

• Most frequent exception types in your logs
• Error messages and call stacks
• Use AI to help you with debugging

2. Exception Metrics

Tracking exception metrics helps you monitor application health and identify trends over time. Use monitoring libraries like Micrometer to collect exception data and visualize it in dashboards.

@Component
public class ExceptionMetrics {
    private final Counter exceptionCounter;
    
    public ExceptionMetrics(MeterRegistry meterRegistry) {
        this.exceptionCounter = Counter.builder("application.exceptions")
            .description("Count of exceptions by type")
            .register(meterRegistry);
    }
    
    public void recordException(Exception e) {
        exceptionCounter.increment(
            Tags.of(
                "exception.type", e.getClass().getSimpleName(),
                "exception.package", e.getClass().getPackage().getName()
            )
        );
    }
}

Quick Reference: Exception Cheat Sheet

Here’s a handy reference for the exceptions covered in this guide:

Frequently Asked Questions

What’s the difference between Exception and RuntimeException?

Exception is the base class for checked exceptions that must be handled at compile time. RuntimeException extends Exception but represents unchecked exceptions that can occur during program execution without requiring explicit handling.

Should I catch Exception or specific exception types?

Always catch specific exception types when possible. Catching the generic Exception can mask unexpected errors and make debugging difficult. Only catch Exception at application boundaries where you need to handle any unexpected error gracefully.

When should I create custom exceptions?

Create custom exceptions when built-in exceptions don’t adequately represent your domain-specific error conditions:

• You need to include additional context information (user ID, transaction ID, etc.)
• Different error types require different handling strategies
• Business rules have specific validation requirements that generic exceptions can’t express
• Your application has distinct failure scenarios that need separate treatment

How do I handle exceptions in streams and lambda expressions?

Java streams don’t handle checked exceptions well. Consider these approaches:

// Wrapper method for checked exceptions
public static <T, R> Function<T, R> unchecked(CheckedFunction<T, R> f) {
    return t -> {
        try {
            return f.apply(t);
        } catch (Exception e) {
            throw new RuntimeException(e);
        }
    };
}

// Usage
list.stream()
    .map(unchecked(this::methodThatThrowsCheckedException))
    .collect(Collectors.toList());

Conclusion

Understanding Java exceptions is fundamental to writing robust applications. From the ubiquitous NullPointerException to domain-specific custom exceptions, each type serves a purpose in communicating what went wrong and how to fix it.

Key takeaways:

• Learn the common exception types and their fully qualified class names
• Handle specific exceptions rather than generic Exception
• Provide meaningful error messages with context
• Use try-with-resources for automatic resource management
• Never swallow exceptions without at least logging them
• Create custom exceptions for domain-specific errors
• Monitor and analyze exception patterns in production

Remember, exceptions are not failures—they’re communication tools. When handled properly, they make your applications more resilient and your debugging sessions more productive.

Deep Dive Exception Guides

Ready to master specific exceptions? These comprehensive guides provide detailed solutions for the most common Java exceptions:

• Fix NullPointerException Fast: Ultimate Java NPE Guide - Master Java’s #1 exception with proven debugging techniques
• Fix ArrayIndexOutOfBounds: Complete Solution Guide - Learn array safety and bounds checking strategies
• IllegalArgumentException: 5 Ways to Fix It Fast - Master parameter validation and defensive programming
• ClassCastException Fixed: Master Type Casting Now - Understand generics and safe type conversions

New to reading error messages? Start with Stack Traces Explained: Complete Beginner’s Guide to decode stack traces like a professional developer.

Need help analyzing complex stack traces? Try Debugly’s stack trace formatter to automatically highlight the most relevant information and streamline your debugging process.