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

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

throws в сигнатуре метода – проброс исключений наверх. Когда это оправдано

Ключевое слово throws в сигнатуре метода Java формирует явный контракт между реализацией и вызывающим кодом. Оно объявляет, что метод может завершиться не нормально, выбросив одно из перечисленных checked-исключений, и перекладывает обязанность обработки на вызывающую сторону. Это часть системы проверяемых исключений Java, где компилятор гарантирует, что каждый potential failure path либо обработан локально, либо явно проброшен дальше по стеку вызовов.

Сигнатура с throws создает сильную связанность (tight coupling) между уровнями абстракции. Когда метод объявляет throws IOException, он экспонирует деталь реализации — использование ввода-вывода — в публичный API. Это называется утечкой абстракции (abstraction leak), когда низкоуровневые детали просачиваются через интерфейсы высокоуровневых компонентов. Вызов такого метода вынуждает все вызывающие методы также объявлять IOException в своих сигнатурах, создавая каскадную зависимость, которая распространяется от инфраструктурного слоя до пользовательского интерфейса.


Когда проброс оправдан: сценарии восстановления

Объявление исключений в сигнатуре методologically оправдано только в ограниченном наборе сценариев.

Первичный критерий — возможность и вероятность восстановления от ошибки на уровне вызывающего кода. Если исключение представляет собой ожидаемое, восстановимое условие, и вызывающий код может принять осмысленное альтернативное действие, тогда throws уместен.

Пример восстановимого сценария — бизнес-исключение InsufficientFundsException в платежной системе. Вызывающий код (координатор транзакции) может перехватить это исключение и предпринять альтернативные действия: предложить пользователю другой способ оплаты, разбить платеж на части, или отложить операцию. В этом случае checked-исключение с throws в сигнатуре метода processPayment форсирует явную обработку критичного бизнес-сценария.

Другой допустимый случай — низкоуровневые API, где пользователь должен осознанно принять решение об обработке ресурсов. Например, конструктор FileInputStream объявляет throws FileNotFoundException, потому что отсутствие файла — это условие, которое вызывающий код может предвидеть и обработать (создать файл, запросить альтернативный путь, продолжить без файла).

Однако современная практика свидетельствует о том, что даже в этих сценариях часто предпочтительны unchecked-исключения с документированием через @throws в Javadoc, а не checked-исключения с throws в сигнатуре.


Exception Translation: оборачивание vs проброс

В многослойной архитектуре прямой проброс низкоуровневых исключений наверх считается антипаттерном. Вместо этого применяется паттерн Exception Translation — перехват низкоуровневого исключения и оборачивание его в высокоуровневое, соответствующее абстракции текущего слоя.

Рассмотрим типичный сценарий с доступом к данным:

// Антипаттерн: прямая передача SQLException через все слои
public User findUser(String id) throws SQLException {  // Нарушение абстракции
    return database.query("SELECT * FROM users WHERE id = ?", id);
}

// Паттерн Exception Translation: оборачивание в доменное исключение
public User findUser(String id) {
    try {
        return database.query("SELECT * FROM users WHERE id = ?", id);
    } catch (SQLException e) {
        throw new DataAccessException("Failed to load user: " + id, e);
    }
}

В этом примере DataAccessException — unchecked-исключение из Spring Framework, которое скрывает детали SQL, но сохраняет оригинальную причину (cause) для отладки. Это достигает нескольких целей: инкапсуляция деталей реализации, предоставление контекстно-зависимого сообщения об ошибке, и поддержание чистоты сигнатур методов бизнес-логики.


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

Важное различие между rethrow (повторным выбросом) и wrap (оборачиванием):
Rethrow — повторный выброс того же исключения без изменения типа, обычно после выполнения некоторых действий (логирование, откат транзакции):

public void processOrder(Order order) throws OrderValidationException {
    try {
        validate(order);
    } catch (OrderValidationException e) {
        auditLog.recordValidationFailure(order.getId(), e);
        throw e;  // Тот же тип, тот же стектрейс
    }
}

Wrap — оборачивание исключения в новый тип, более подходящий для абстракции, с сохранением оригинальной причины:

public Configuration loadConfiguration() {
    try {
        return parser.parse(configFile);
    } catch (IOException e) {
        throw new ConfigurationLoadException("Cannot read config from " + configFile, e);
    }
}

При wrap критически важно передавать оригинальное исключение в конструктор нового исключения как cause. Это сохраняет полный стектрейс и позволяет при отладке проследить цепочку ошибок от высокоуровневого бизнес-сбоя до низкоуровневой технической причины.


Проблема интерфейсов и полиморфизма

Checked-исключения создают особые сложности при проектировании интерфейсов. Метод интерфейса, объявляющий throws CheckedException, обязывает все реализации работать с этим типом ошибки, даже если конкретная реализация не способна выбросить такое исключение.

// Интерфейс объявляет checked-исключение
interface DataStore {
    String read(String key) throws IOException;
}

// Реализация на основе памяти не может выбросить IOException,
// но вынуждена объявлять его или оборачивать в RuntimeException
class InMemoryStore implements DataStore {
    @Override
    public String read(String key) throws IOException {  // Нелогично
        return memoryMap.get(key);
    }
}

Это нарушает принцип подстановки Лисков и создает искусственные ограничения для реализаций. Современный подход — использование unchecked-исключений в интерфейсах с документированием возможных сбоев через Javadoc, что позволяет реализациям самостоятельно решать, какие исключения выбрасывать, не нарушая контракт интерфейса.


Несовместимость с функциональным стилем

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

// Метод с checked-исключением не может быть использован как лямбда
public String fetchUrl(String url) throws IOException {
    return httpClient.get(url);
}

// Ошибка компиляции: IOException не обработано
List<String> results = urls.stream()
    .map(this::fetchUrl)  // Не компилируется
    .collect(Collectors.toList());

Это архитектурное ограничение Java 8 фактически сигнализировало о том, что checked-исключения являются устаревшей концепцией для современного Java. Разработчики вынуждены прибегать к оборачиванию checked-исключений в RuntimeException внутри лямбд, что разрушает систему типов и делает checked-исключения бесполезными.


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

Современная философия: minimal throws

Современные best practices в Java-разработке рекомендуют минимальное использование throws в сигнатурах методов.

Основные принципы:
Unchecked by default: Используйте unchecked-исключения для большинства сценариев, документируя их через @throws в Javadoc.
Exception Translation на границах слоев: Перехватывайте низкоуровневые checked-исключения (SQL, IO) и оборачивайте их в высокоуровневые unchecked на границе инфраструктурного слоя.
Централизованная обработка: Используйте глобальные обработчики исключений (например, @ControllerAdvice в Spring) для преобразования исключений в HTTP-ответы или сообщения пользователю, вместо распределенной обработки через throws.
Не декларируйте unchecked: Хотя синтаксически возможно объявлять throws RuntimeException, это считается плохой практикой, так как не предоставляет полезной информации, но загромождает сигнатуру.

Пример современного подхода в Spring-приложении:

// Сервис не объявляет throws, использует unchecked
@Service
public class OrderService {
    public Order processOrder(OrderRequest request) {
        validate(request);  // Может выбросить ValidationException (unchecked)
        
        try {
            return orderRepository.save(request.toEntity());
        } catch (DataAccessException e) {  // Unchecked от Spring
            throw new OrderProcessingException("Failed to save order", e);
        }
    }
    
    private void validate(OrderRequest request) {
        if (request.getAmount() <= 0) {
            throw new ValidationException("Amount must be positive");
        }
    }
}

// Глобальная обработка без распространения throws через слои
@RestControllerAdvice
public class GlobalExceptionHandler {
    
    @ExceptionHandler(ValidationException.class)
    public ResponseEntity<ErrorResponse> handleValidation(ValidationException e) {
        return ResponseEntity.badRequest()
            .body(new ErrorResponse(e.getMessage()));
    }
    
    @ExceptionHandler(OrderProcessingException.class)
    public ResponseEntity<ErrorResponse> handleProcessing(OrderProcessingException e) {
        return ResponseEntity.status(HttpStatus.INTERNAL_SERVER_ERROR)
            .body(new ErrorResponse("Order processing failed"));
    }
}

Документирование исключений

Когда throws используется, критически важно документировать каждое объявленное исключение в Javadoc с помощью тега @throws. Это объясняет, при каких условиях возникает исключение, и помогает вызывающему коду решить, нужно ли его обрабатывать.

/**
 * Загружает конфигурацию приложения из файла.
 *
 * @param path путь к файлу конфигурации
 * @return загруженная конфигурация
 * @throws ConfigLoadException если файл не существует, недоступен для чтения,
 *         или содержимое не соответствует ожидаемому формату
 */
public Configuration loadConfiguration(Path path) {
    // Реализация
}

Даже для unchecked-исключений современная практика рекомендует использовать @throws для документирования возможных сбоев, сохраняя при этом сигнатуры методов чистыми от throws.


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