Почему существует иерархия исключений в Java?

Иерархия исключений в Java

Иерархия исключений — это фундаментальная концепция Java, которая обеспечивает гибкую обработку ошибок. Расскажу о причинах её существования.

Иерархия исключений

Throwable (top level)
├── Exception (проверяемые и непроверяемые)
│   ├── Checked Exceptions
│   │   ├── IOException
│   │   ├── SQLException
│   │   └── ClassNotFoundException
│   │
│   └── RuntimeException (непроверяемые)
│       ├── NullPointerException
│       ├── ArrayIndexOutOfBoundsException
│       ├── ArithmeticException
│       └── IllegalArgumentException
│
└── Error (невосстанавливаемые ошибки)
    ├── OutOfMemoryError
    ├── StackOverflowError
    └── VirtualMachineError

Основные причины иерархии

1. Гранулярная обработка ошибок

Иерархия позволяет обрабатывать разные типы ошибок по-разному:

public class FileProcessor {
    public void processFile(String filename) {
        try {
            File file = new File(filename);
            FileReader reader = new FileReader(file);
            String content = readContent(reader);
            parseContent(content);
            reader.close();
        } catch (FileNotFoundException e) {
            // Файл не найден — логируем и уведомляем пользователя
            logger.error("File not found: " + filename, e);
            sendUserNotification("Пожалуйста, проверьте имя файла");
        } catch (IOException e) {
            // Ошибка чтения файла — переполняемся на резервный механизм
            logger.error("Failed to read file", e);
            fallbackToCache(filename);
        } catch (ParseException e) {
            // Ошибка парсинга — возвращаем по умолчанию
            logger.error("Failed to parse content", e);
            return getDefaultContent();
        }
    }
}

Без иерархии пришлось бы использовать проверку типа:

// Плохо — без иерархии
try {
    processFile(filename);
} catch (Throwable e) {
    if (e.getMessage().contains("File not found")) {
        // ...
    } else if (e.getMessage().contains("Parse error")) {
        // ...
    }
}

2. Разделение проверяемых и непроверяемых исключений

Checked Exceptions: Принуждают программиста обработать ошибку или передать её выше:

public void saveToDatabase(User user) throws SQLException {
    // SQLException — проверяемое исключение
    // Компилятор требует либо try-catch, либо throws
    String sql = "INSERT INTO users VALUES (...)";
    Connection conn = DriverManager.getConnection(dbUrl);
    PreparedStatement stmt = conn.prepareStatement(sql);
    // ...
}

// Вызывающий код ДОЛЖЕН обработать
try {
    saveToDatabase(user);
} catch (SQLException e) {
    // Обработка
}

Unchecked Exceptions: Не требуют обработки, но программист может обработать, если хочет:

public int divide(int a, int b) {
    // ArithmeticException — необработанное исключение
    // Компилятор НЕ требует try-catch
    return a / b;  // Может выбросить ArithmeticException
}

// Вызывающий код может НЕ обрабатывать
int result = divide(10, 2);

// Но может обработать, если хочет
try {
    result = divide(10, 0);
} catch (ArithmeticException e) {
    result = 0;
}

3. Полиморфизм при обработке

Иерархия позволяет ловить группы исключений по super-типу:

public class DataService {
    public User loadUser(int id) {
        try {
            return userRepository.findById(id);
        } catch (SQLException | IOException e) {
            // Оба — типы Exception, можем ловить вместе
            logger.error("Failed to load user", e);
            throw new DataAccessException("Cannot access data", e);
        }
    }
}

Или ловить всё, что наследует Exception:

try {
    // Код, который может выбросить разные исключения
    processUserData();
} catch (Exception e) {
    // Ловим ВСЕ исключения (проверяемые и непроверяемые)
    logger.error("Operation failed", e);
}

4. Контрактная обработка (Contract-based handling)

Деклариация в сигнатуре метода:

// Явно говорим: этот метод может выбросить IOException или SQLException
public void loadAndSaveUser(int id) throws IOException, SQLException {
    User user = loadFromFile(id);      // может выбросить IOException
    saveToDatabase(user);              // может выбросить SQLException
}

// Вызывающий код знает, что нужно обработать эти исключения
try {
    loadAndSaveUser(123);
} catch (IOException e) {
    logger.error("File error", e);
} catch (SQLException e) {
    logger.error("Database error", e);
}

5. Информативность stack trace

Кажда исключение содержит информацию о том, где произошла ошибка:

java.io.FileNotFoundException: /data/users.txt (No such file or directory)
    at java.io.FileInputStream.open(FileInputStream.java:195)
    at java.io.FileInputStream.<init>(FileInputStream.java:138)
    at java.io.FileReader.<init>(FileReader.java:72)
    at com.example.UserLoader.loadUsers(UserLoader.java:15)
    at com.example.Application.main(Application.java:8)

Этот trace показывает точную цепочку вызовов и строку, где произошла ошибка.

6. Правильное проектирование (Design pattern)

Иерархия позволяет следовать принципу Liskov Substitution Principle:

public abstract class CustomException extends Exception {
    public abstract void handle();
}

public class ValidationException extends CustomException {
    @Override
    public void handle() {
        logger.warn("Validation failed: " + getMessage());
    }
}

public class DatabaseException extends CustomException {
    @Override
    public void handle() {
        logger.error("Database operation failed", this);
        // trigger database failover
    }
}

// Полиморфная обработка
public void processWithErrorHandling() {
    try {
        processData();
    } catch (CustomException e) {
        e.handle();  // Каждый тип обрабатывает себя сам
    }
}

7. Создание custom исключений

Мы можем создавать свои исключения для бизнес-логики:

// Business exceptions
public class InsufficientFundsException extends Exception {
    private final BigDecimal required;
    private final BigDecimal available;
    
    public InsufficientFundsException(BigDecimal required, BigDecimal available) {
        super(String.format("Required: %s, Available: %s", required, available));
        this.required = required;
        this.available = available;
    }
    
    public BigDecimal getShortfall() {
        return required.subtract(available);
    }
}

// Использование
public void withdraw(Account account, BigDecimal amount) throws InsufficientFundsException {
    if (account.getBalance().compareTo(amount) < 0) {
        throw new InsufficientFundsException(amount, account.getBalance());
    }
    account.setBalance(account.getBalance().subtract(amount));
}

// Специализированная обработка
try {
    withdraw(account, withdrawAmount);
} catch (InsufficientFundsException e) {
    BigDecimal shortfall = e.getShortfall();
    System.out.println("Not enough money. Shortfall: " + shortfall);
    // Предлагаем кредит или отклоняем операцию
}

8. Правильное управление ресурсами

Тry-with-resources использует иерархию для закрытия ресурсов:

// AutoCloseable — часть иерархии
public void readFile(String filename) throws IOException {
    try (FileReader reader = new FileReader(filename)) {
        // Если выбросится исключение, reader закроется автоматически
        String line;
        // ...
    } catch (IOException e) {
        logger.error("Failed to read", e);
    }
    // reader.close() вызывается автоматически
}

Антипаттерны

Что НЕ нужно делать:

// ❌ Ловим общее Exception
try {
    doSomething();
} catch (Exception e) {
    // Скрываем специфический тип ошибки
    e.printStackTrace();
}

// ❌ Переводим checked в unchecked без смысла
public void load() {
    try {
        loadFromDatabase();  // throws SQLException
    } catch (SQLException e) {
        throw new RuntimeException(e);  // Потеряли информацию типа
    }
}

// ❌ Пустой catch
try {
    doSomething();
} catch (Exception e) {
    // Игнорируем ошибку!
}

Итого

Иерархия исключений существует для:

1. Гранулярной обработки — разные типы ошибок, разное поведение
2. Type safety — компилятор проверяет обработку checked exceptions
3. Полиморфизма — можем ловить группы исключений
4. Контракта — сигнатура метода явно указывает на возможные ошибки
5. Информативности — каждый тип ошибки содержит релевантную информацию
6. Расширяемости — можем создавать свои типы исключений
7. Правильного дизайна — позволяет построить надёжную систему обработки ошибок

Без иерархии программист бы вынужден писать хрупкий код с частыми if-else проверками на строки сообщений об ошибке.