JV Java · 20 вопросов · ~55 мин · ⏱ Таймер 55:00 · Лёгкий ·

Исключения и ресурсы

Проверяет основу темы «Исключения и ресурсы» через чтение кода, предсказание результата и выбор корректной конструкции. Вопросы перемешаны: встречаются трассировка, ошибка компиляции, выбор правки, граничный сценарий и оценка инженерного компромисса. Базовая версия — Java 25 LTS; если версия не названа отдельно, используются устойчивые правила, совместимые с Java 21.

Отвечено: 0 из 20

⏱ --:--

💡 Инструкция: Выберите один ответ из пяти. На 20 вопросов отведено 55 минут. В каждом вопросе верен только один вариант; близкие ответы различаются стадией ошибки, порядком действий или границей контракта. После завершения вы увидите общий результат, результаты по 4 тематическим шкалам и объяснения.

Вопрос 1 из 20

Как поведёт себя фрагмент по теме «Проектирование ошибок» при разборе раздела «Исключения и ресурсы»?

try {
    return parseOrder(text);
} catch (Exception e) {
    return null;
}

Сначала закрывается second, затем first; если тело уже выбросило исключение, ошибки закрытия сохраняются как подавленные. Ловля Exception скрывает и ожидаемую ошибку формата, и программные дефекты вроде NullPointerException. Ловля Exception скрывает и ожидаемую ошибку формата, и программные дефекты вроде IllegalStateException. Сравнение x == y истинно для 100 из-за кэша Integer, а для 1000 полагаться на идентичность нельзя. После throw new ServiceException("load failed") без cause трассировка теряет исходную SQLException.

Вопрос 2 из 20

Какой контракт языка или библиотеки точнее всего описывает тему «Проверяемые и непроверяемые исключения» в разделе «Исключения и ресурсы»?

Checked-исключение должно быть обработано или объявлено, unchecked обычно сообщает о нарушении программного контракта. Set хранит уникальные элементы согласно equals и hashCode либо результату Comparator для сортированного множества. Автоупаковка создаёт или переиспользует объект-обёртку, а распаковка null вызывает NullPointerException. Переопределяющий метод должен сохранять совместимую сигнатуру; возвращаемый ссылочный тип может быть ковариантным. Checked-исключение должно быть обработано или объявлено, checked обычно сообщает о нарушении программного контракта.

Вопрос 3 из 20

Каков точный результат выполнения или компиляции фрагмента из раздела «Исключения и ресурсы» по теме «Проверяемые и непроверяемые исключения»?

static String read(java.nio.file.Path p) {
    return java.nio.file.Files.readString(p);
}

Метод read не компилируется без catch или throws UncheckedIOException. Метод read не компилируется без catch или throws IOException. Второй put возвращает 1 и оставляет под ключом x значение 2. После throw new ServiceException("load failed") без cause трассировка теряет исходную SQLException. Метод write не компилируется без catch или throws IOException.

Вопрос 4 из 20

В каком дополнительном сценарии вывод о теме «Проектирование ошибок» в разделе «Исключения и ресурсы» может оказаться неверным?

// ...
    return parseOrder(text);
} catch (Exception e) {
    return null;
}

Кэш Integer обязателен как минимум для диапазона -128..127, но реализация может расширять его. Переменная ресурса должна быть final или фактически неизменяемой, если объявлена вне заголовка try. Возврат null вместо ошибки может быть уместен только при явно договорённом отсутствии результата. get возвращает null и для отсутствующего ключа, и для ключа со значением null; различить случаи помогает containsKey. Неизменяемость String не делает ссылочную переменную final; её можно связать с другой строкой.

Вопрос 5 из 20

Какая правка точнее всего устраняет причину проблемы по теме «Проверяемые и непроверяемые исключения» в разделе «Исключения и ресурсы»?

// Фрагмент на ревью
static String read(java.nio.file.Path p) {
    return java.nio.file.Files.readString(p);
}

Создать ServiceException с сообщением и исходным исключением либо вызвать initCause. Использовать try с ресурсами для каждого AutoCloseable и не терять подавленные исключения при оборачивании. Либо обработать ошибку на уровне, способном восстановиться, либо объявить её и сохранить контекст. Перехватывать конкретное исключение, добавлять контекст и оставлять неожиданные ошибки видимыми. Не использовать ковариантный массив как универсальный контейнер; выбрать List<Object> при смешанных типах.

Вопрос 6 из 20

Как лучше исправить или прояснить поведение темы «Цепочка причин» в разделе «Исключения и ресурсы»?

// Фрагмент на ревью
try {
    repository.load(id);
} catch (java.sql.SQLException e) {
    throw new ServiceException("load failed");
}

Использовать try с ресурсами для каждого AutoCloseable и не терять подавленные исключения при оборачивании. Для удаления значения вызвать remove(Integer.valueOf(1)) или removeIf. Перехватывать конкретное исключение, добавлять контекст и оставлять неожиданные ошибки видимыми. Создать ServiceException с сообщением и исходным исключением либо вызвать initCause. Либо обработать ошибку на уровне, способном восстановиться, либо объявить её и сохранить контекст.

Вопрос 7 из 20

Какое замечание о сопровождении или производительности темы «Цепочка причин» в разделе «Исключения и ресурсы» справедливо?

Исключения упрощают основной путь, но слишком мелкая иерархия типов усложняет API без дополнительной пользы. Массивы компактны и быстры для фиксированного размера, но ковариантность переносит часть проверки типов во время выполнения. Автоматическое закрытие сокращает пути утечки, но порядок ресурсов всё равно важен при зависимостях между ними. Предметная ошибка изолирует слой, но сообщение и исходная причина должны позволять восстановить техническую первопричину. Checked полезны для ожидаемых восстановимых сбоев, но чрезмерно широкие throws Exception размывают контракт.

Вопрос 8 из 20

Каков точный результат выполнения или компиляции фрагмента из раздела «Исключения и ресурсы» по теме «Автоматическое закрытие ресурсов»?

try (var first = open("first");
     var second = open("second")) {
    throw new IllegalStateException("body");
}

Вызов trim() игнорируется, поэтому печатается строка с исходными пробелами. После throw new ServiceException("load failed") без cause трассировка теряет исходную SQLException. Сначала закрывается second, затем first; если тело уже выбросило исключение, ошибки закрытия сохраняются как подавленные. Метод read не компилируется без catch или throws IOException. Ловля Exception скрывает и ожидаемую ошибку формата, и программные дефекты вроде NullPointerException.

Вопрос 9 из 20

Что важно учитывать при применении механизма «Автоматическое закрытие ресурсов» из раздела «Исключения и ресурсы» в рабочем проекте?

Checked полезны для ожидаемых восстановимых сбоев, но чрезмерно широкие throws Exception размывают контракт. Автоматическое закрытие сокращает пути утечки, но порядок ресурсов всё равно важен при зависимостях между ними. Исключения упрощают основной путь, но слишком мелкая иерархия типов усложняет API без дополнительной пользы. Предметная ошибка изолирует слой, но сообщение и исходная причина должны позволять восстановить техническую первопричину. String удобен для безопасного совместного использования, а StringBuilder — для серии изменений в одном потоке.

Вопрос 10 из 20

Какой контракт языка или библиотеки точнее всего описывает тему «Проектирование ошибок» в разделе «Исключения и ресурсы»?

Автоупаковка создаёт или переиспользует объект-обёртку, а распаковка null вызывает NullPointerException. List сохраняет порядок и допускает дубликаты; удаление по индексу и по значению выбирается перегрузкой. Строковые литералы интернируются, а new String создаёт отдельный объект даже при том же содержимом. Исключение должно сообщать о нарушенном контракте и не использоваться как обычный механизм ветвления. Map связывает уникальный ключ со значением; повторный put заменяет значение для равного ключа.

Вопрос 11 из 20

На какое правило следует опираться при разборе темы «Цепочка причин» в разделе «Исключения и ресурсы»?

При переводе исключения между слоями исходную причину надо сохранять в поле cause. List сохраняет порядок и допускает дубликаты; удаление по индексу и по значению выбирается перегрузкой. Checked-исключение должно быть обработано или объявлено, unchecked обычно сообщает о нарушении программного контракта. Ресурсы закрываются в обратном порядке объявления, а исключения из close могут сохраняться как подавленные. Исключение должно сообщать о нарушенном контракте и не использоваться как обычный механизм ветвления.

Вопрос 12 из 20

Какой контракт языка или библиотеки точнее всего описывает тему «Автоматическое закрытие ресурсов» в разделе «Исключения и ресурсы»?

Автоупаковка создаёт или переиспользует объект-обёртку, а распаковка null вызывает NullPointerException. Ресурсы закрываются в обратном порядке объявления, а исключения из flush могут сохраняться как подавленные. Исключение должно сообщать о нарушенном контракте и не использоваться как обычный механизм ветвления. При переводе исключения между слоями исходную причину надо сохранять в поле cause. Ресурсы закрываются в обратном порядке объявления, а исключения из close могут сохраняться как подавленные.

Вопрос 13 из 20

Какой граничный случай особенно важен для темы «Автоматическое закрытие ресурсов» в разделе «Исключения и ресурсы»?

Повторное журналирование одного исключения на каждом слое создаёт шум и дубликаты без дополнительного контекста. Неизменяемость String не делает ссылочную переменную final; её можно связать с другой строкой. Оборачивание checked-исключения в RuntimeException не устраняет причину; её следует передать как cause. Переменная ресурса должна быть final или фактически неизменяемой, если объявлена вне заголовка try. Возврат null вместо ошибки может быть уместен только при явно договорённом отсутствии результата.

Вопрос 14 из 20

Какое замечание о сопровождении или производительности темы «Проектирование ошибок» в разделе «Исключения и ресурсы» справедливо?

Map ускоряет поиск по ключу, но качество и неизменность ключа критичны для хеш-реализаций. Исключения упрощают основной путь, но слишком мелкая иерархия типов усложняет API без дополнительной пользы. Автоматическое закрытие сокращает пути утечки, но порядок ресурсов всё равно важен при зависимостях между ними. String удобен для безопасного совместного использования, а StringBuilder — для серии изменений в одном потоке. Интернирование уменьшает дубли строк, но переносит их в глобальный пул и может увеличить удерживаемую память.

Вопрос 15 из 20

Что произойдёт с кодом по теме «Цепочка причин» в разделе «Исключения и ресурсы»?

try {
    repository.load(id);
} catch (java.sql.SQLException e) {
    throw new ServiceException("load failed");
}

Присваивание String[] в Object[] компилируется, но запись Integer вызывает ArrayStoreException. Ловля Exception скрывает и ожидаемую ошибку формата, и программные дефекты вроде NullPointerException. После throw new ServiceException("load failed") без cause трассировка теряет исходную SQLException. Метод read не компилируется без catch или throws IOException. Сначала закрывается second, затем first; если тело уже выбросило исключение, ошибки закрытия сохраняются как подавленные.

Вопрос 16 из 20

Какое ограничение механизма «Цепочка причин» нельзя упускать при работе с разделом «Исключения и ресурсы»?

// ...
    repository.load(id);
} catch (java.sql.SQLException e) {
    throw new ServiceException("load failed");
}

clone создаёт новый массив, но для массива ссылок копия остаётся поверхностной. Повторное журналирование одного исключения на каждом слое не создаёт шум и дубликаты без дополнительного контекста. Возврат null вместо ошибки может быть уместен только при явно договорённом отсутствии результата. Переменная ресурса должна быть final или фактически неизменяемой, если объявлена вне заголовка try. Повторное журналирование одного исключения на каждом слое создаёт шум и дубликаты без дополнительного контекста.

Вопрос 17 из 20

Какое изменение сделает код по теме «Автоматическое закрытие ресурсов» в разделе «Исключения и ресурсы» надёжнее?

// Фрагмент на ревью
try (var first = open("first");
     var second = open("second")) {
    throw new IllegalStateException("body");
}

Перехватывать конкретное исключение, добавлять контекст и оставлять неожиданные ошибки видимыми. Создать ServiceException с сообщением и исходным исключением либо вызвать initCause. Использовать putIfAbsent, compute или merge, когда замена должна зависеть от предыдущего состояния. Либо обработать ошибку на уровне, способном восстановиться, либо объявить её и сохранить контекст. Использовать try с ресурсами для каждого AutoCloseable и не терять подавленные исключения при оборачивании.

Вопрос 18 из 20

Какой граничный случай особенно важен для темы «Проверяемые и непроверяемые исключения» в разделе «Исключения и ресурсы»?

Кэш Integer обязателен как минимум для диапазона -128..127, но реализация может расширять его. Оборачивание checked-исключения в RuntimeException не устраняет причину; её следует передать как cause. Неизменяемость String не делает ссылочную переменную final; её можно связать с другой строкой. Оборачивание unchecked-исключения в RuntimeException не устраняет причину; её следует передать как cause. HashSet не обещает порядок обхода, LinkedHashSet сохраняет порядок вставки, TreeSet — сортировку.

Вопрос 19 из 20

Какое замечание о сопровождении или производительности темы «Проверяемые и непроверяемые исключения» в разделе «Исключения и ресурсы» справедливо?

String удобен для безопасного совместного использования, а StringBuilder — для серии изменений в одном потоке. Переопределение даёт полиморфизм, но контракт базового типа важнее удобства отдельного наследника. Интернирование уменьшает дубли строк, но переносит их в глобальный пул и может увеличить удерживаемую память. Checked полезны для ожидаемых восстановимых сбоев, но чрезмерно широкие throws Exception размывают контракт. Автоматическое закрытие сокращает пути утечки, но порядок ресурсов всё равно важен при зависимостях между ними.

Вопрос 20 из 20

Какая правка точнее всего устраняет причину проблемы по теме «Проектирование ошибок» в разделе «Исключения и ресурсы»?

// Фрагмент на ревью
try {
    return parseOrder(text);
} catch (Exception e) {
    return null;
}

Перехватывать конкретное исключение, добавлять контекст и оставлять неожиданные ошибки видимыми. Использовать try с ресурсами для каждого AutoCloseable и не терять подавленные исключения при оборачивании. Сохранить catch (Exception), но вместо null возвращать заранее созданный пустой Order. Сравнивать значения обёрток через equals или распаковывать только после проверки null. Создать ServiceException с сообщением и исходным исключением либо вызвать initCause.

Ответьте на все 20 вопросов, чтобы получить результат

🔗 Встроить тест на свой сайт (iframe) ▼

Скопируйте код и вставьте в любое место на вашем сайте:

Также доступна прямая ссылка на embed-страницу