Раздел 10. Исключения, логирование, отладка

Глава 1. Иерархия исключений (Exceptions)

Checked vs Unchecked исключения: когда что использовать.

Разделение исключений на checked и unchecked в Java основано на фундаментальном различии между двумя категориями проблем. Проверяемые исключения (checked) предназначены для ситуаций, которые клиентский код может разумно ожидать и от которых может восстановиться. Непроверяемые исключения (unchecked) сигнализируют о программных ошибках, которые должны быть исправлены в коде, а не обработаны во время выполнения.

Классическое правило, сформулированное в документации Oracle, гласит: если клиент может разумно ожидать восстановления от исключения, сделайте его проверяемым. Если клиент не может ничего сделать для восстановления, сделайте его непроверяемым. Это различие отражает два разных мира: внешние, непредсказуемые условия (отсутствие файла, недоступность сети) против внутренних нарушений контрактов (передача null вместо валидного аргумента, выход за границы массива).

Однако за четверть века существования Java эта модель подверглась серьезной критике и эволюции. Современные фреймворки и языки на JVM демонстрируют явный сдвиг в сторону unchecked-исключений даже для традиционно checked-сценариев.


Механика checked-исключений: контракты и обязательства

Checked-исключения представляют собой часть сигнатуры метода, формируя контракт между вызывающим и вызываемым кодом. Когда метод объявляет throws IOException, он явно заявляет о возможности сбоя ввода-вывода, обязывая вызывающий код либо обработать эту ситуацию через try-catch, либо передать ответственность дальше по стеку вызовов. Этот механизм создает цепочку ответственности.

Рассмотрим шесть уровней вызовов между точкой возникновения исключения и его обработкой: каждый промежуточный метод должен либо поймать исключение, либо добавить его в свою сигнатуру throws. Это приводит к эффекту загрязнения сигнатур (signature pollution), когда изменение в низкоуровневом методе вынуждает обновлять десятки сигнатур выше по стеку.

Практический пример демонстрирует эту проблему:

// Низкоуровневый метод работы с базой данных
public User findById(String id) throws SQLException {
    Connection conn = dataSource.getConnection();
    // ... выполнение запроса
}

// Сервисный слой вынужден пробрасывать checked-исключение
public User getUser(String id) throws SQLException {
    return userRepository.findById(id);
}

// Контроллер также заражен checked-исключением
public UserDto getUserEndpoint(String id) throws SQLException {
    User user = userService.getUser(id);
    return userMapper.toDto(user);
}

В этой иерархии SQLException пронизывает все слои приложения, нарушая принцип разделения ответственности. Контроллер, отвечающий за HTTP-протокол, вынужден знать о деталях работы с базой данных, что создает нежелательную связанность (coupling) между модулями.


Unchecked-исключения: свобода и ответственность

Unchecked-исключения, наследующие RuntimeException, не требуют объявления в сигнатурах методов. Они могут возникнуть в любом месте и распространяться по стеку вызовов до тех пор, пока не будут перехвачены или не приведут к завершению потока. Эта модель освобождает разработчика от обязательной обработки каждого возможного сбоя, но требует дисциплины в проектировании границ транзакций и обработки ошибок.

Ключевое преимущество unchecked-исключений — сохранение чистоты сигнатур методов. Метод может сосредоточиться на своей основной ответственности, не загромождая сигнатуру перечнем возможных сбоев. Обработка ошибок откладывается на уровень, обладающий достаточным контекстом для принятия решений: retry, fallback, уведомление пользователя или аварийное завершение операции.


#Java #для_новичков #beginner #exception #checked #unchecked

Пример рефакторинга предыдущего кода в unchecked-стиле:

// Кастомное unchecked-исключение для домена
public class UserNotFoundException extends RuntimeException {
    private final String userId;
    
    public UserNotFoundException(String userId) {
        super("User not found: " + userId);
        this.userId = userId;
    }
}

// Репозиторий скрывает детали SQL, транслирует в доменное исключение
public User findById(String id) {
    try {
        Connection conn = dataSource.getConnection();
        // ... выполнение запроса
    } catch (SQLException e) {
        throw new DataAccessException("Database error while loading user", e);
    }
}

// Сервисный слой чист, без throws
public User getUser(String id) {
    return userRepository.findById(id)
        .orElseThrow(() -> new UserNotFoundException(id));
}

// Контроллер также чист, фокусируется на HTTP-логике
public UserDto getUserEndpoint(String id) {
    User user = userService.getUser(id);
    return userMapper.toDto(user);
}

В этом варианте SQLException перехватывается на границе инфраструктурного слоя и транслируется в DataAccessException — unchecked-исключение из Spring Framework. Доменное исключение UserNotFoundException также unchecked, так как отсутствие пользователя — это валидный бизнес-сценарий, который контроллер обрабатывает через глобальный обработчик исключений, преобразуя в HTTP 404.


Эволюция Spring Framework: от checked к unchecked

Spring Framework стал одним из первых major-фреймворков, систематически отказавшихся от checked-исключений. Философия Spring заключается в том, что большинство исключений в enterprise-приложениях — это фатальные сбои текущей операции, от которых невозможно восстановиться на месте.

Центральным элементом этой стратегии является иерархия DataAccessException. Spring перехватывает низкоуровневые checked-исключения (SQLException, HibernateException, JPAException) и транслирует их в структурированную иерархию unchecked-исключений: DataRetrievalFailureException, DataIntegrityViolationException, QueryTimeoutException и другие. Это достигается двумя целями: абстрагирование от конкретной технологии доступа к данным и признание того, что большинство ошибок базы данных фатальны для текущей транзакции.

Пример интеграции с Spring Data:

@Repository
public interface OrderRepository extends JpaRepository<Order, Long> {
    // Метод объявлен без throws, но может выбросить unchecked исключения
    Optional<Order> findByOrderNumber(String orderNumber);
}

@Service
public class OrderService {
    @Autowired
    private OrderRepository orderRepository;
    
    @Transactional
    public Order processOrder(String orderNumber) {
        // Никаких try-catch для checked-исключений
        Order order = orderRepository.findByOrderNumber(orderNumber)
            .orElseThrow(() -> new OrderNotFoundException(orderNumber));
        
        // При ошибке базы данных будет выброшено DataAccessException
        // Транзакция откатится автоматически
        return executeBusinessLogic(order);
    }
}

В этом коде отсутствуют объявления throws, несмотря на потенциальные сбои базы данных. Spring управляет транзакциями через @Transactional, и любое unchecked-исключение приводит к автоматическому откату.

Обработка ошибок централизована через @ControllerAdvice:

@ControllerAdvice
public class GlobalExceptionHandler {
    
    @ExceptionHandler(DataAccessException.class)
    public ResponseEntity<ErrorResponse> handleDatabaseError(DataAccessException e) {
        // Логирование, метрики, уведомление
        return ResponseEntity.status(HttpStatus.SERVICE_UNAVAILABLE)
            .body(new ErrorResponse("Database temporarily unavailable"));
    }
    
    @ExceptionHandler(OrderNotFoundException.class)
    public ResponseEntity<ErrorResponse> handleNotFound(OrderNotFoundException e) {
        return ResponseEntity.status(HttpStatus.NOT_FOUND)
            .body(new ErrorResponse(e.getMessage()));
    }
}

#Java #для_новичков #beginner #exception #checked #unchecked

Этот подход разделяет бизнес-логику и обработку ошибок. Бизнес-код остается чистым и сфокусированным, в то время как обработка ошибок концентрируется в специализированных компонентах с полным контекстом HTTP-запроса.


Kotlin: полный отказ от checked-исключений

Kotlin пошел дальше, полностью устранив концепцию checked-исключений из языка. Все исключения в Kotlin по умолчанию unchecked, что соответствует философии минимизации шаблонного кода (boilerplate) и прагматичной разработки.

Это решение было обусловлено накопившимися проблемами checked-исключений в Java: многословностью, разрушением композиции в функциональном стиле, принуждением к плохим практикам (пустые catch-блоки, оборачивание в RuntimeException) и несовместимостью с лямбда-выражениями. Как отмечают разработчики Kotlin, за 25 лет checked-исключения в Java продемонстрировали столько же проблем, сколько решений, и ни один другой язык не принял эту модель .

В Kotlin код обработки ошибок выглядит естественно:

fun updateOrderQuantity(orderId: OrderId, quantity: Int) {
    require(quantity > 0) { "Quantity must be positive" }
    val order = loadOrder(orderId)  // Может выбросить исключение, но не требует try-catch
    order.quantity = quantity
    storeOrder(order)  // То же самое
}

Ключевая концепция Kotlin — централизованная обработка I/O-ошибок. Вместо разбросанных по коду try-catch блоков для каждой сетевой операции, Kotlin предлагает выносить обработку на границу между бизнес-логикой и пользовательским интерфейсом. Это соответствует реальности enterprise-приложений, где сетевые сбои обрабатываются единообразно: retry с экспоненциальным backoff, fallback к кэшу или уведомление пользователя о временной недоступности сервиса.

Для взаимодействия с Java-кодом, использующим checked-исключения, Kotlin предоставляет аннотацию @Throws, которая генерирует соответствующие сигнатуры в байткоде для Java-вызывающих сторон. Однако внутри Kotlin- codebase эта информация не используется для статической проверки.


Фатальный удар: checked-исключения и Java 8 Streams

Введение лямбда-выражений и Stream API в Java 8 выявило фундаментальную несовместимость checked-исключений с функциональным программированием. Функциональные интерфейсы (Function<T,R>, Consumer<T>, Supplier<T>) не объявляют checked-исключений в своих абстрактных методах, что делает невозможным прямое использование методов, бросающих checked-исключения, в лямбдах.

Рассмотрим попытку использовать метод, объявляющий throws IOException, внутри Stream.map():

// Метод с checked-исключением
public String fetchDataFromUrl(String url) throws IOException {
    return httpClient.fetch(url);
}

// Невозможно напрямую использовать в Stream
List<String> urls = List.of("http://api1.com", "http://api2.com");
List<String> data = urls.stream()
    .map(this::fetchDataFromUrl)  // Ошибка компиляции: IOException не обработано
    .collect(Collectors.toList());

Разработчики вынуждены прибегать к обходным маневрам: оборачиванию исключений в RuntimeException внутри лямбды, созданию специальных функциональных интерфейсов с throws, или использованию библиотек вроде Vavr. Все эти решения уродливы и разрушают элегантность функционального стиля.

Пример оборачивания, который демонстрирует проблему:

List<String> data = urls.stream()
    .map(url -> {
        try {
            return fetchDataFromUrl(url);
        } catch (IOException e) {
            throw new RuntimeException(e);  // Уничтожение семантики checked-исключения
        }
    })
    .collect(Collectors.toList());

Эта ситуация привела к тому, что комитет по развитию Java фактически признал checked-исключения тупиковой ветвью эволюции языка. Отсутствие поддержки checked-исключений в Stream API — это не oversight, а осознанное решение, демонстрирующее, что checked-исключения и современный Java несовместимы.


#Java #для_новичков #beginner #exception #checked #unchecked

Современные best practices: доминирование unchecked

Современные рекомендации по проектированию исключений в Java существенно эволюционировали. Если ранее считалось нормой делать все восстановимые сбои checked, то теперь преобладает подход "unchecked by default" с несколькими четкими критериями для исключений.

Используйте checked-исключения только когда:
- Восстановление возможно и вероятно на месте вызова. Пример: повторная попытка при временном сбое сети с backoff, запрос альтернативного ввода от пользователя.
- Исключение является частью доменной модели и требует явного внимания клиента. Пример: бизнес-исключение InsufficientFundsException в финансовой системе, где вызывающий код должен явно обработать сценарий недостаточности средств.
- API предназначен для широкого использования внешними клиентами, и пропуск исключения приведет к катастрофическим последствиям.

Во всех остальных случаях используйте unchecked-исключения:
- Программные ошибки (null-аргументы, выход за границы, нарушение инвариантов).
- Фатальные сбои внешних систем (база данных недоступна, сетевой таймаут), где восстановление требует транзакционной логики на более высоком уровне.
- Сценарии, где исключение транслируется через несколько слоев абстракции перед обработкой.
- Код, интегрирующийся с функциональными API (Streams, CompletableFuture, Optional).

Пример проектирования современного API:

// Checked-исключение для редкого, но критичного сценария восстановления
public class PaymentReversalRequiredException extends Exception {
    private final Payment originalPayment;
    private final String reasonCode;
    
    public PaymentReversalRequiredException(Payment payment, String reasonCode, String message) {
        super(message);
        this.originalPayment = payment;
        this.reasonCode = reasonCode;
    }
    
    // Методы доступа для логики восстановления
    public Payment getOriginalPayment() { return originalPayment; }
    public String getReasonCode() { return reasonCode; }
}

// Unchecked-исключения для всех остальных сценариев
public class PaymentProcessingException extends RuntimeException {
    private final String transactionId;
    
    public PaymentProcessingException(String transactionId, String message, Throwable cause) {
        super(message, cause);
        this.transactionId = transactionId;
    }
}

public class InvalidPaymentRequestException extends IllegalArgumentException {
    private final String fieldName;
    
    public InvalidPaymentRequestException(String fieldName, Object value) {
        super(String.format("Invalid value for field %s: %s", fieldName, value));
        this.fieldName = fieldName;
    }
}

PaymentReversalRequiredException — checked, потому что требует немедленного действия: отката платежа, уведомления бухгалтерии, возможно, ручного вмешательства. Это редкий, но критичный бизнес-сценарий.
PaymentProcessingException — unchecked, так как ошибки процессинга (таймаут, недоступность шлюза) фатальны для текущей операции и обрабатываются централизованно через retry-механизм или circuit breaker.
InvalidPaymentRequestException — unchecked, так как передача невалидных данных — это ошибка вызывающего кода, которая должна быть исправлена до деплоя.


#Java #для_новичков #beginner #exception #checked #unchecked

Паттерн "Railway Oriented Programming" и альтернативы исключениям

В функциональном стиле, особенно при работе с Kotlin или современными Java-библиотеками, исключения часто заменяются на типы-результаты (Result types). Это позволяет явно моделировать ошибки в типовой системе без checked-исключений.

Пример с использованием библиотеки Vavr:

import io.vavr.control.Either;
import io.vavr.control.Try;

public Either<PaymentError, PaymentReceipt> processPayment(PaymentRequest request) {
    return validateRequest(request)
        .flatMap(this::authorizePayment)
        .flatMap(this::executeTransfer)
        .map(this::generateReceipt);
}

private Either<PaymentError, ValidatedRequest> validateRequest(PaymentRequest request) {
    if (request.getAmount() <= 0) {
        return Either.left(new PaymentError("INVALID_AMOUNT", "Amount must be positive"));
    }
    if (request.getCurrency() == null) {
        return Either.left(new PaymentError("MISSING_CURRENCY", "Currency is required"));
    }
    return Either.right(new ValidatedRequest(request));
}

В этом подходе ошибки — это значения (values), а не исключительные ситуации. Клиентский код вынужден обрабатывать оба случая (success и failure) через pattern matching или методы fold, getOrElse, orElseThrow. Это устраняет проблему "забытого catch-блока", присущую unchecked-исключениям, без возврата к verbosity checked-исключений.


#Java #для_новичков #beginner #exception #checked #unchecked