Java for Beginner

Здесь важен порядок закрытия: ресурсы должны освобождаться в обратном порядке их создания. Вложенные try-finally обеспечивают, что fis будет закрыт даже если fos.close() выбросит исключение. Однако этот код все еще уязвим: если fis.close() выбросит исключение, оно замаскирует любое исключение из основного блока, что делает отладку чрезвычайно сложной.

Опасные взаимодействия: finally и return

Одна из наиболее коварных особенностей finally — его взаимодействие с оператором return. Блок finally выполняется после вычисления возвращаемого значения, но фактически до выхода из метода, что создает возможность для подавления или модификации результата.

Рассмотрим классический пример подавления исключения:

public int problematicMethod() {
    try {
        throw new RuntimeException("Critical error");
    } finally {
        return 42;  // Исключение будет подавлено!
    }
}

В этом коде исключение из try-блока никогда не достигнет вызывающего метода. JVM выполняет finally, встречает return, и завершает метод со значением 42. Это не просто плохая практика — это семантически некорректное поведение, которое нарушает контракт метода и делает невозможным обнаружение ошибок .

Другой вариант той же проблемы — модификация возвращаемого значения:

public int confusingMethod() {
    int result = 0;
    try {
        result = 10;
        return result;
    } finally {
        result = 20;  // Это изменение проигнорируется!
    }
}

Здесь метод вернет 10, а не 20. JVM сохраняет значение 10 в отдельной локальной переменной перед входом в finally, и восстанавливает его после завершения finally.

Однако если finally содержит собственный return, он переопределяет сохраненное значение:

public int anotherConfusingMethod() {
    try {
        return 10;
    } finally {
        return 20;  // Теперь вернет 20
    }
}

Эти примеры демонстрируют, что return в finally — это не просто code smell, а активно вредная практика, которую следует категорически запрещать в code style guidelines.

Обработка исключений при закрытии ресурсов

При закрытии ресурсов в finally возникает дополнительная проблема: сам метод close() может выбросить исключение. В классическом подходе это приводит к подавлению исходного исключения:

public void readAndProcess(String path) throws IOException {
    BufferedReader reader = null;
    try {
        reader = new BufferedReader(new FileReader(path));
        process(reader);
    } finally {
        if (reader != null) {
            reader.close();  // Если здесь IOException, исходное исключение потеряно
        }
    }
}

Если process(reader) выбросит DataFormatException, а reader.close() выбросит IOException, вызывающий метод получит только IOException. Информация о реальной причине ошибки (некорректный формат данных) будет утрачена. Это критично для диагностики проблем в production.

Для сохранения исходного исключения требовался изощренный паттерн:

public void readAndProcessSafe(String path) throws IOException {
    BufferedReader reader = null;
    IOException originalException = null;
    try {
        reader = new BufferedReader(new FileReader(path));
        process(reader);
    } catch (IOException e) {
        originalException = e;
        throw e;
    } finally {
        if (reader != null) {
            try {
                reader.close();
            } catch (IOException closeException) {
                if (originalException != null) {
                    originalException.addSuppressed(closeException);
                } else {
                    throw closeException;
                }
            }
        }
    }
}

Этот код использует механизм suppressed exceptions, появившийся в Java 7, но реализованный вручную. Он сохраняет ссылку на исходное исключение, и при возникновении исключения при закрытии добавляет его как "подавленное" к исходному. Это сохраняет полную картину ошибки, но ценой чрезвычайной сложности кода.

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

👍3

62 views08:59