C# C# · 20 вопросов · ~55 мин · ⏱ Таймер 55:00 · Средний ·

Исключения и освобождение ресурсов

Проверяет исключения и владение ресурсами: порядок catch/finally, сохранение стека, фильтры, using, IDisposable и асинхронное освобождение. Сценарии требуют отличать обработанную ошибку от скрытой и выбирать границу, на которой сбой действительно можно исправить.

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

⏱ --:--

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

Вопрос 1 из 20

Почему catch (Exception) должен идти после catch (FormatException)?

try { Parse(input); }
catch (FormatException ex) { HandleBadFormat(ex); }
catch (Exception ex) { HandleUnexpected(ex); }

Порядок не имеет значения FormatException сначала преобразуется в Exception, а обратный порядок меняет только текст сообщения FormatException не наследует Exception Узкий catch обязан быть finally Общий catch иначе перехватит FormatException

Вопрос 2 из 20

Чем throw; отличается от throw ex; внутри catch?

catch (Exception ex)
{
    logger.LogError(ex, "failed");
    throw;
}

throw; сохраняет исходную трассировку throw ex; создаёт новую оболочку с исходным исключением внутри throw ex; быстрее Ничем throw; разрешён только для null

Вопрос 3 из 20

Когда exception filter when полезен?

Когда нужно гарантировать освобождение ресурса вместо finally Когда исключение нужно преобразовать в другой тип до входа в catch Когда catch нужен только для исключения с определённым кодом или состоянием Когда операцию нужно повторять без ограничения числа попыток Когда требуется заменить проверку аргументов перехватом всех исключений

Вопрос 4 из 20

Какой подход лучше для ожидаемо неверного пользовательского числа?

catch(Exception) вокруг всего запроса int.TryParse и обычная ветвь результата int.Parse и исключение на каждую ошибку throw null Environment.FailFast

Вопрос 5 из 20

Какая строка получится после перехвата FormatException и продолжения выполнения?

try { _ = int.Parse("x"); }
catch (FormatException) { Console.Write("caught"); }
Console.Write("done");

Пустая строка: после выполнения catch управление не переходит к коду после try/catch caughtdone caught done Программа не компилируется

Вопрос 6 из 20

Выполнится ли finally при return из try?

static int M()
{
    try { return 1; }
    finally { Console.Write("F"); }
}

Да, перед фактическим возвратом Только для void Только если возвращаемое значение имеет ссылочный тип Нет: оператор return пропускает блок finally Нет

Вопрос 7 из 20

Когда finally может не выполниться?

try
{
    Environment.FailFast("fatal");
}
finally
{
    Console.WriteLine("cleanup");
}

При обычном исключении, покидающем блок try При FailFast, крахе процесса или обрыве питания При continue, переходящем к следующей итерации При return, завершающем метод внутри try При FormatException без подходящего catch

Вопрос 8 из 20

Почему опасно бросать новое исключение из finally?

Исключение из finally подавляется, если try уже завершился ошибкой Это меняет тип ресурса CLR завершит только текущий цикл Новое исключение может скрыть исходное finally запрещает throw

Вопрос 9 из 20

Какой порядок вывода?

try { Console.Write("T"); }
finally { Console.Write("F"); }

TF FT Пустая строка: finally выполняется лишь при исключении внутри try F T

Вопрос 10 из 20

Что лучше для простого IDisposable-ресурса?

Полагаться на финализатор даже тогда, когда тип обещает детерминированный Dispose Использовать using, который гарантирует Dispose через схему try/finally Открыть ресурс до try и закрыть только после успешного завершения работы Вызвать полную сборку мусора после каждой операции с ресурсом Сохранить ресурс в статическом поле и закрыть при завершении процесса

Вопрос 11 из 20

Когда вызовется Dispose у using declaration?

using var stream = File.OpenRead(path);
ReadHeader(stream);
ReadBody(stream);
// Dispose в конце текущего блока

Dispose вызывается только у классического using-блока После следующей сборки мусора Только при исключении Сразу после строки объявления В конце текущей области видимости

Вопрос 12 из 20

Что делает Dispose?

using var stream = File.OpenRead(path);
ReadHeader(stream);
// Dispose будет вызван при выходе из области.

Останавливает GC Обязательно освобождает память объекта немедленно Вызывает финализатор дважды Удаляет все ссылки на объект Освобождает ресурсы согласно контракту типа

Вопрос 13 из 20

Как освобождать IAsyncDisposable?

await using var connection = await OpenAsync();
await connection.SendAsync(data);

GC.WaitForPendingFinalizers await using в async-контексте Вызвать обычный Dispose в синхронном finally и не ждать завершения С помощью lock Обычный using синхронно вызывает DisposeAsync

Вопрос 14 из 20

В каком порядке освобождаются вложенные using?

Одновременно Только первый ресурс В порядке создания В обратном порядке создания В порядке успешного завершения конструкторов ресурсов

Вопрос 15 из 20

Нужно ли вручную Dispose сервис, полученный из DI-контейнера?

Да, сразу после каждого метода Контейнер вызывает финализатор сервиса вместо Dispose Только если сервис singleton Обычно нет: Dispose выполняет контейнер-владелец Только в контроллере

Вопрос 16 из 20

Когда отдельный InsufficientBalanceException оправдан?

Когда вызывающему коду нужно отдельно распознать нехватку средств и обработать её Когда сообщение об ошибке не должно содержать никаких данных Когда хочется заменить проверку остатка перехватом общего Exception Когда в журнале нужна другая формулировка той же технической ошибки Когда ошибка возникает только внутри private-метода и не пересекает границу

Вопрос 17 из 20

Зачем передавать исходное исключение как innerException?

catch (SqlException ex)
{
    throw new OrderStorageException(orderId, ex);
}

Сохраняет исходную причину вместе с новым контекстом Чтобы catch не сработал innerException нужен сериализатору для восстановления типа ошибки Чтобы удалить его трассировку Чтобы исключение стало warning

Вопрос 18 из 20

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

Выбрать Exception, чтобы вызывающий код не зависел от вида проверки StackOverflowException ArgumentException либо ArgumentOutOfRangeException NullReferenceException вручную TaskCanceledException

Вопрос 19 из 20

Что следует хранить в пользовательском исключении?

Ссылку на Thread Код причины и идентификатор операции без секретов Весь объект запроса без фильтрации Пароли и токены для удобства Только идентификатор операции без кода причины и безопасных параметров

Вопрос 20 из 20

Когда лучше вернуть Result/ошибку как значение, а не бросать?

При StackOverflowException При нарушении внутреннего инварианта Когда отказ ожидаем и является одной из обычных бизнес-ветвей При невозможности открыть обязательную конфигурацию на старте При повреждении памяти

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

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

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

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