Расширенная обработка ошибок — бесплатный тест онлайн

Вопрос 1 из 25

Что ещё нужно проверить, прежде чем считать реализацию «Классификация ошибок» надёжной?

ErrorKind помечен как non_exhaustive, поэтому match должен иметь резервную ветвь и не считать текущий список вечным. Ошибки данных и инфраструктуры можно объединить в один вариант без последствий для восстановления. Отмена между побочным эффектом и повтором не создаёт риска дублирования операции. Повтор операции можно не ограничивать, поскольку постоянная ошибка рано или поздно станет временной. Если функция возвращает Result, она не может оставить частично изменённое состояние.

Вопрос 2 из 25

Как переписать код так, чтобы край контракта был виден в типе результата?

#[derive(Debug)]
enum ConfigError {
    Io { path: std::path::PathBuf, source: std::io::Error },
    InvalidPort { value: String },
}

При ошибке `derive` возвращать значение по умолчанию, не сообщая вызывающему коду причину и возможность восстановления. Считать полный текст Display стабильным машинным кодом ошибки для ветвления и тестов. Сигнатура при этом почти не меняется, однако исходное предусловие остаётся скрытым. Заменить обработку результата `derive` на `unwrap` или `expect`, сохранив прежний возвращаемый тип функции. Нарушение условия превращается в панику вместо явного результата, который мог бы обработать вызывающий код. Считать этот отказ нарушением внутреннего инварианта и использовать `panic!`, не меняя публичный договор «Thiserror-подобные модели». Для библиотечного API определить устойчивые варианты и источники; производные макросы использовать для рутинной реализации, а не для замены проектирования категорий.

Вопрос 3 из 25

Какой результат следует из типов и порядка действий?

fn load_or_default(path: &str) -> Result<String, std::io::Error> {
    match std::fs::read_to_string(path) {
        Ok(v) => Ok(v),
        Err(e) if e.kind() == std::io::ErrorKind::NotFound => Ok(String::new()),
        Err(e) => Err(e),
    }
}

Проверка типов завершится ошибкой: пользовательский тип ошибки обязан хранить строку и не может быть enum. Код не пройдёт проверку: result нельзя возвращать из обычной функции без async. Сборка пройдёт, поскольку повтор операции безопасен для любой ошибки, если сделать достаточно попыток. Функция восстанавливается только при отсутствии файла и сохраняет остальные ошибки, не маскируя отказ доступа или повреждение ввода. Код пройдёт проверку компилятора: строковый текст ошибки сохраняет тип причины и автоматическую цепочку source.

Вопрос 4 из 25

Какой принцип Rust объясняет обычный сценарий для «Тестирование и инструменты Cargo»?

Строковый текст ошибки сохраняет тип причины и автоматическую цепочку source. Контракт «Тестирование и инструменты Cargo» считался бы одинаковым при любом состоянии входа. Source строится автоматически из текста Display без явной связи между ошибками. Тогда различия между обычным и граничным случаем для «Тестирование и инструменты Cargo» исчезли бы. Все ошибки ввода-вывода можно повторять, потому что они по определению временные. Проверку ошибки для «Тестирование и инструменты Cargo» при таком подходе заменили бы успешным примером. Контекст можно добавлять без сохранения исходной ошибки, потому что текст полностью заменяет тип. Хороший тест ошибки отличает машинный контракт от человекочитаемого текста и отдельно проверяет восстановление и невосстанавливаемый путь.

Вопрос 5 из 25

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

Ошибки данных и инфраструктуры можно объединить в один вариант без последствий для восстановления. Текст ошибки можно сравнивать дословно во всех версиях зависимостей и локалях. Поэтому отдельный результат ошибки и отрицательный тест для этого случая не предусматриваются. Безусловный unwrap_or_default может скрыть отказ инфраструктуры и превратить ошибку в правдоподобные пустые данные, усложняя расследование. Если функция возвращает Result, она не может оставить частично изменённое состояние. Документация и тип результата тогда могут не оговаривать частичное выполнение или раннее завершение. Повтор операции можно не ограничивать, поскольку постоянная ошибка рано или поздно станет временной. Тогда поведение «Восстановление» при раннем выходе выводили бы из обычного пути.

Вопрос 6 из 25

Какое правило Rust точнее всего описывает механизм «Классификация ошибок»?

Строковый текст ошибки сохраняет тип причины и автоматическую цепочку source. Тогда различия между обычным и граничным случаем для «Классификация ошибок» исчезли бы. Классификация нужна там, где категория определяет действие: повтор, запасной путь, ответ пользователю или немедленный отказ. Source строится автоматически из текста Display без явной связи между ошибками. Тогда поведение «Классификация ошибок» при раннем выходе выводили бы из обычного пути. Option и Result отличаются только названиями вариантов и взаимозаменяемы без потери контракта. Повтор операции безопасен для любой ошибки, если сделать достаточно попыток. Проверку ошибки для «Классификация ошибок» при таком подходе заменили бы успешным примером.

Вопрос 7 из 25

Какая часть механизма «Классификация ошибок» зафиксирована тестом `std::io::ErrorKind`?

fn retryable(kind: std::io::ErrorKind) -> bool {
    matches!(kind, std::io::ErrorKind::Interrupted | std::io::ErrorKind::WouldBlock)
}

Результат можно считать доказательством свойства языка, даже если он зависит от конкретной библиотеки или платформы. Функция делает политику повтора явной и тестируемой; она не повторяет PermissionDenied или InvalidData без основания. Отсутствие сообщения инструмента означает, что опасная ветвь была выполнена и признана корректной. Если сценарий проходит в debug-сборке, в release и на другой целевой платформе результат будет тем же. Успешный запуск подтверждает корректность не только этого пути, но и остальных ветвей программы.

Вопрос 8 из 25

Что Rust гарантирует при корректном использовании «Восстановление»?

Option и Result отличаются только названиями вариантов и взаимозаменяемы без потери контракта. Тогда поведение «Восстановление» при раннем выходе выводили бы из обычного пути. Все ошибки ввода-вывода можно повторять, потому что они по определению временные. Тогда поведение «Восстановление» при раннем выходе выводили бы из обычного пути. Повтор операции безопасен для любой ошибки, если сделать достаточно попыток. Тогда поведение «Восстановление» при раннем выходе выводили бы из обычного пути. Восстановление корректно только для ошибки, после которой известен безопасный альтернативный результат или повтор с ограниченной политикой. Строковый текст ошибки сохраняет тип причины и автоматическую цепочку source. Следовательно, поведение `std::io::Error` считалось бы одинаковым для всех допустимых типов.

Вопрос 9 из 25

Почему типы, владение или доступы здесь несовместимы?

#[derive(Debug)]
enum ConfigError {
    Io { path: std::path::PathBuf, source: std::io::Error },
    InvalidPort { value: String },
}

Компилятор примет фрагмент: пользовательский тип ошибки обязан хранить строку и не может быть enum. Сборка пройдёт, поскольку контекст можно добавлять без сохранения исходной ошибки, потому что текст полностью заменяет тип. Код пройдёт проверку компилятора: контекст ошибки запрещает использовать оператор source. Значит, выполнение должно пройти через `std::path::PathBuf` без изменения сигнатуры. Фрагмент успешно соберётся: строковый текст ошибки сохраняет тип причины и автоматическую цепочку source. Enum разделяет категории ошибки и хранит структурный контекст; derive-библиотека может сгенерировать Display и Error без потери source.

Вопрос 10 из 25

Какой эксплуатационный край отличает контракт «Тестирование и инструменты Cargo» от удачного примера?

Ошибки данных и инфраструктуры можно объединить в один вариант без последствий для восстановления. Документация и тип результата тогда могут не оговаривать частичное выполнение или раннее завершение. Фиксированное имя отсутствующего файла может внезапно существовать; надёжнее создавать уникальный временный каталог и контролировать его содержимое. После добавления контекста исходную причину и её тип проверять не нужно. Контракт «Тестирование и инструменты Cargo» считался бы одинаковым при любом состоянии входа. Если функция возвращает Result, она не может оставить частично изменённое состояние. Проверку ошибки для «Тестирование и инструменты Cargo» при таком подходе заменили бы успешным примером. Текст ошибки можно сравнивать дословно во всех версиях зависимостей и локалях. Такое рассуждение переносило бы вывод о «Тестирование и инструменты Cargo» на неисполненную ветвь.

Вопрос 11 из 25

На какую часть контракта распространяется проверка `std::env::temp_dir`?

let temp = std::env::temp_dir().join("definitely_missing_config_1242");
let value = load_or_default(temp.to_str().unwrap()).unwrap();
assert!(value.is_empty());

Если сценарий проходит в debug-сборке, в release и на другой целевой платформе результат будет тем же. Дополнительный сценарий вокруг `std::env::temp_dir` при таком толковании уже не требуется. Диагностика инструмента сама однозначно подсказывает безопасное исправление, поэтому разбирать контракт отдельно не нужно. Дополнительный сценарий вокруг `std::env::temp_dir` при таком толковании уже не требуется. Тест проверяет конкретный fallback NotFound; отдельный тест должен убедиться, что PermissionDenied не превращается в пустую строку. Если основной путь стабилен, ранний выход и повторный вход можно не воспроизводить отдельно. Отсутствие ошибки компиляции уже доказывает нужное свойство, поэтому поведение можно не проверять.

Вопрос 12 из 25

Какая переделка сохраняет стоимость операции предсказуемой?

#[test]
fn preserves_error_category() {
    let e = std::fs::read_to_string("missing-file-for-test").unwrap_err();
    assert_eq!(e.kind(), std::io::ErrorKind::NotFound);
}

Считать этот отказ нарушением внутреннего инварианта и использовать `panic!`, не меняя публичный договор «Тестирование и инструменты Cargo». При ошибке `preserves_error_category` возвращать значение по умолчанию, не сообщая вызывающему коду причину и возможность восстановления. Для ошибок проверять вариант, важные поля, source chain и отсутствие секретов в пользовательском сообщении; snapshot полного Debug использовать осторожно. Заменить обработку результата `preserves_error_category` на `unwrap` или `expect`, сохранив прежний возвращаемый тип функции. Считать полный текст Display стабильным машинным кодом ошибки для ветвления и тестов. Сигнатура при этом почти не меняется, однако исходное предусловие остаётся скрытым. Следовательно, для `preserves_error_category` не понадобилось бы явное предусловие.

Вопрос 13 из 25

Какой узкий вывод следует из проверки `preserves_error_category`?

#[test]
fn preserves_error_category() {
    let e = std::fs::read_to_string("missing-file-for-test").unwrap_err();
    assert_eq!(e.kind(), std::io::ErrorKind::NotFound);
}

Тест проверяет структурную категорию ошибки, а не полный Display-текст, который зависит от платформы и локали. Код компилируется и даёт ожидаемый результат: контекст можно добавлять без сохранения исходной ошибки, а текст полностью заменяет тип. Код считается допустимым, потому что строковый текст ошибки сохраняет тип причины и автоматическую цепочку source. Код компилируется, но цепочка причин собирается только из текста Display и не зависит от типов. Сборка остановится: контекст ошибки запрещает использовать оператор source.

Вопрос 14 из 25

Какое объяснение механизма «Thiserror-подобные модели» не смешивает компиляцию и выполнение?

Контекст можно добавлять без сохранения исходной ошибки, потому что текст полностью заменяет тип. Тогда поведение «Thiserror-подобные модели» при раннем выходе выводили бы из обычного пути. Source строится автоматически из текста Display без явной связи между ошибками. Тогда поведение «Thiserror-подобные модели» при раннем выходе выводили бы из обычного пути. Thiserror-подобный подход сохраняет типизированную ошибку и автоматически связывает source и Display, не меняя семантику публичного enum. Типизированная ошибка мешает добавлять контекст, поэтому приложение должно хранить только String. Строковый текст ошибки сохраняет тип причины и автоматическую цепочку source. Контракт «Thiserror-подобные модели» считался бы одинаковым при любом состоянии входа.

Вопрос 15 из 25

Как правильно прочитать результат диагностического сценария `std::error::Error`?

fn load(path: &str) -> Result<String, Box<dyn std::error::Error + Send + Sync>> {
    Ok(std::fs::read_to_string(path)?)
}

# В журнал выводят полную цепочку причин, пользователю — краткое сообщение без секретов.

Одного успешного примера достаточно, чтобы считать проверенными и невыполненные ветви контракта. Разделение сообщений предотвращает утечку путей, токенов и внутренних деталей, сохраняя подробную цепочку в защищённой диагностике. Совпадение полного текста диагностики является главным и стабильным контрактом этой проверки. Диагностика инструмента сама однозначно подсказывает безопасное исправление, поэтому разбирать контракт отдельно не нужно. Если сценарий проходит в debug-сборке, в release и на другой целевой платформе результат будет тем же. Дополнительный сценарий вокруг `std::error::Error` при таком толковании уже не требуется.

Вопрос 16 из 25

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

match error.kind() {
    std::io::ErrorKind::NotFound => create_default(),
    std::io::ErrorKind::PermissionDenied => return Err(error.into()),
    _ => return Err(error.into()),
}

Заменить обработку результата `error` на `unwrap` или `expect`, сохранив прежний возвращаемый тип функции. Определить закрытый перечень категорий, по которым меняется поведение; неизвестные причины сохранять и передавать наружу без ложного восстановления. При ошибке `error` возвращать значение по умолчанию, не сообщая вызывающему коду причину и возможность восстановления. Считать этот отказ нарушением внутреннего инварианта и использовать `panic!`, не меняя публичный договор «Классификация ошибок». Возвращать None вместо всех ошибок: вызывающему коду не нужно знать причину отказа. Сигнатура при этом почти не меняется, однако исходное предусловие остаётся скрытым.

Вопрос 17 из 25

Что можно считать доказанным после успешного выполнения `preserves_error_category`?

#[test]
fn preserves_error_category() {
    let e = std::fs::read_to_string("missing-file-for-test").unwrap_err();
    assert_eq!(e.kind(), std::io::ErrorKind::NotFound);
}

# cargo test preserves_error_category -- --exact

Изолированный запуск удобен, но сам тест должен создавать собственное окружение, чтобы параллельные тесты и файлы разработчика не меняли результат. Результат можно считать доказательством свойства языка, даже если он зависит от конкретной библиотеки или платформы. Успешный запуск подтверждает корректность не только этого пути, но и остальных ветвей программы. Дополнительный сценарий вокруг `preserves_error_category` при таком толковании уже не требуется. Совпадение полного текста диагностики является главным и стабильным контрактом этой проверки. Соседние ветви ошибки, отмены и частичного выполнения тогда считают проверенными автоматически. Один положительный сценарий покрывает контракт целиком, включая частичный результат и преждевременное завершение.

Вопрос 18 из 25

Что нужно проверить отдельно при переносе механизма «Thiserror-подобные модели» в библиотечный код?

Ошибки данных и инфраструктуры можно объединить в один вариант без последствий для восстановления. Текст ошибки можно сравнивать дословно во всех версиях зависимостей и локалях. Документация и тип результата тогда могут не оговаривать частичное выполнение или раннее завершение. Если функция возвращает Result, она не может оставить частично изменённое состояние. Отмена между побочным эффектом и повтором не создаёт риска дублирования операции. Документация и тип результата тогда могут не оговаривать частичное выполнение или раннее завершение. Текст сообщения не является стабильным машинным контрактом; пользователи должны сопоставлять варианты или публичные методы, если библиотека это обещает.

Вопрос 19 из 25

Что ещё нужно проверить, прежде чем считать реализацию «anyhow-подобный контекст» надёжной?

Повтор операции можно не ограничивать, поскольку постоянная ошибка рано или поздно станет временной. Стирание типа усложняет программное ветвление по категориям и может превратить ожидаемый сценарий восстановления в анализ строк или downcast. Если функция возвращает Result, она не может оставить частично изменённое состояние. Поэтому ошибочный сценарий вокруг «anyhow-подобный контекст» не проверяли бы отдельно. Отмена между побочным эффектом и повтором не создаёт риска дублирования операции. Документация и тип результата тогда могут не оговаривать частичное выполнение или раннее завершение. Тогда поведение «anyhow-подобный контекст» при раннем выходе выводили бы из обычного пути. Ошибки данных и инфраструктуры можно объединить в один вариант без последствий для восстановления. Документация и тип результата тогда могут не оговаривать частичное выполнение или раннее завершение. Проверку ошибки для «anyhow-подобный контекст» при таком подходе заменили бы успешным примером.

Вопрос 20 из 25

Какой узкий вывод следует из проверки `ConfigError::Io`?

fn kind(e: &ConfigError) -> &'static str {
    match e { ConfigError::Io { .. } => "io", ConfigError::InvalidPort { .. } => "input" }
}

Отсутствие сообщения инструмента означает, что опасная ветвь была выполнена и признана корректной. Отдельная классификация по вариантам устойчива к изменению Display и локализации сообщений. Совпадение полного текста диагностики является главным и стабильным контрактом этой проверки. Диагностика инструмента сама однозначно подсказывает безопасное исправление, поэтому разбирать контракт отдельно не нужно. Дополнительный сценарий вокруг `ConfigError::Io` при таком толковании уже не требуется. Если сценарий проходит в debug-сборке, в release и на другой целевой платформе результат будет тем же.

Вопрос 21 из 25

Как изменятся значения к моменту завершения блока?

match error.kind() {
    std::io::ErrorKind::NotFound => create_default(),
    std::io::ErrorKind::PermissionDenied => return Err(error.into()),
    _ => return Err(error.into()),
}

Код считается допустимым, потому что строковый текст ошибки сохраняет тип причины и автоматическую цепочку source. Проверку ошибки для `kind` при таком подходе заменили бы успешным примером. Фрагмент успешно соберётся: повтор операции безопасен для любой ошибки, если сделать достаточно попыток. Код не пройдёт проверку: option требует отдельного null-указателя в памяти для каждого значения. Код различает восстанавливаемое отсутствие файла и отказ в доступе; классификация основана на ErrorKind, а не на тексте ОС. Код компилируется, но none и Err различаются только форматом печати, но не управлением выполнением.

Вопрос 22 из 25

Что изменить, чтобы ответственность за освобождение ресурса не дублировалась?

fn load(path: &str) -> Result<String, Box<dyn std::error::Error + Send + Sync>> {
    Ok(std::fs::read_to_string(path)?)
}

Считать этот отказ нарушением внутреннего инварианта и использовать `panic!`, не меняя публичный договор «anyhow-подобный контекст». При ошибке `load` возвращать значение по умолчанию, не сообщая вызывающему коду причину и возможность восстановления. На границах приложения добавлять цепочечный контекст к универсальной ошибке; в библиотечном API предпочесть собственный тип, если вызывающему нужно восстановление. Добавить один общий вариант Other(String) и преобразовывать в него все ошибки до классификации. Сигнатура при этом почти не меняется, однако исходное предусловие остаётся скрытым. Заменить обработку результата `load` на `unwrap` или `expect`, сохранив прежний возвращаемый тип функции. Нарушение условия превращается в панику вместо явного результата, который мог бы обработать вызывающий код.

Вопрос 23 из 25

Какое свойство «anyhow-подобный контекст» сохранится после небольшого рефакторинга?

Типизированная ошибка мешает добавлять контекст, поэтому приложение должно хранить только String. Такое рассуждение переносило бы вывод о «anyhow-подобный контекст» на неисполненную ветвь. Строковый текст ошибки сохраняет тип причины и автоматическую цепочку source. В результате «anyhow-подобный контекст» считали бы безопасным и на путях, которых пример не выполняет. Повтор операции безопасен для любой ошибки, если сделать достаточно попыток. Тогда поведение «anyhow-подобный контекст» при раннем выходе выводили бы из обычного пути. Контекст можно добавлять без сохранения исходной ошибки, потому что текст полностью заменяет тип. Такое рассуждение переносило бы вывод о «anyhow-подобный контекст» на неисполненную ветвь. Anyhow-подобная ошибка удобна для распространения разнородных причин и контекста в приложении, сохраняя source chain для диагностики.

Вопрос 24 из 25

Какое изменение делает ответственность за данные явной в этом фрагменте?

fn load_or_default(path: &str) -> Result<String, std::io::Error> {
    match std::fs::read_to_string(path) {
        Ok(v) => Ok(v),
        Err(e) if e.kind() == std::io::ErrorKind::NotFound => Ok(String::new()),
        Err(e) => Err(e),
    }
}

Преобразовать каждую ошибку в String в самом нижнем слое и удалить исходный тип причины. Сигнатура при этом почти не меняется, однако исходное предусловие остаётся скрытым. Считать этот отказ нарушением внутреннего инварианта и использовать `panic!`, не меняя публичный договор «Восстановление». Заменить обработку результата `load_or_default` на `unwrap` или `expect`, сохранив прежний возвращаемый тип функции. Ограничить fallback точно определённой категорией и записать, считается ли пустое значение валидным; остальные причины вернуть с контекстом. При ошибке `load_or_default` возвращать значение по умолчанию, не сообщая вызывающему коду причину и возможность восстановления.

Вопрос 25 из 25

Что произойдёт после операции `std::error::Error`?

fn load(path: &str) -> Result<String, Box<dyn std::error::Error + Send + Sync>> {
    Ok(std::fs::read_to_string(path)?)
}

Код считается допустимым, потому что строковый текст ошибки сохраняет тип причины и автоматическую цепочку source. Тогда поведение `load` при раннем выходе выводили бы из обычного пути. Функция стирает конкретный тип ошибки для верхнего слоя приложения, но в таком виде не добавляет сведения об операции и пути. Этот фрагмент будет отклонён: контекст ошибки запрещает использовать оператор source. Код компилируется и даёт ожидаемый результат: контекст можно добавлять без сохранения исходной ошибки, а текст полностью заменяет тип. Поэтому ошибочный сценарий вокруг `load` не проверяли бы отдельно. Проверка типов пропустит этот путь: повтор операции безопасен для любой ошибки, если сделать достаточно попыток.