Задание: сравнить семантику исключений в Java и механизмы обработки ошибок в Rust (Result/Option) и показать, как разные подходы влияют на дизайн API и обработку ошибок в критичных системах.
Цели
- Понять семантику и виды ошибок в Java (checked/unchecked, RuntimeException, Error, finally/try-with-resources) и в Rust (Result, Option, panic, ?-оператор, Drop).
- Реализовать одинаковую функциональность в Java и Rust с учётом идиоматичной обработки ошибок.
- Проанализировать, как выбор механизма ошибок влияет на API (сигнатуры, композиция, документированность), на надёжность и поведение в критичных системах (детерминированность очистки ресурсов, возможности проверки на этапе компиляции, отказоустойчивость).
- Подготовить отчёт с выводами и рекомендациями для критичных систем.
Требования и предварительные условия
- Знание Java и Rust на уровне практического кодирования.
- Среда для сборки/запуска: JDK 8+ и cargo.
- Объём отчёта: 3–6 страниц + код в репозитории.
Часть A — теоретическое сравнение (коротко)
1. Опишите семантику ошибок в Java:
- checked vs unchecked exceptions; когда и зачем используются checked exceptions;
- исключения приводят к unwinding стека; finally/try-with-resources для очистки.
2. Опишите семантику ошибок в Rust:
- типы Result и Option, явная обработка; panic для неустранимых ошибок;
- ?-оператор для удобной передачи ошибок;
- RAII/Drop для детерминированной очистки.
3. Кратко перечислите сильные и слабые стороны каждого подхода с точки зрения критичных систем (детерминированность, обнаруживаемость ошибок на этапе компиляции, производительность, читаемость API).
Часть B — практическая реализация (обязательно)
Реализуйте небольшую библиотеку/модуль с одинаковой функциональностью в Java и Rust. Предлагаемая задача: безопасная транзакционная запись в файл с возможностью отката при ошибке и отчётом о типе ошибки.
Требования к реализации:
- API должен позволять:
- открыть/создать «транзакцию» над файлом;
- записать несколько записей;
- зафиксировать (commit) или откатить (rollback) транзакцию;
- возвращать понятные ошибки вызывающему.
- Обработку ресурсов сделать безопасной (ресурсы всегда освобождаются).
- В Java: используйте идиоматичную обработку исключений (checked/unchecked по назначению), try-with-resources, явную документацию throws.
- В Rust: используйте Result/Option и ?-оператор; моделируйте ошибки через enum; используйте RAII для очистки.
Минимальные примеры (схематичные)
Java (схема):
class Transaction implements AutoCloseable {
public Transaction(Path p) throws IOException { ... }
public void write(byte[] data) throws IOException { ... }
public void commit() throws IOException { ... }
public void rollback() { ... }
public void close() { /* гарантированная очистка */ }
}
Использование:
try (Transaction tx = new Transaction(path)) {
tx.write(data);
tx.commit();
} catch (IOException e) {
// обработка ошибок
}
Rust (схема):
enum Error { Io(std::io::Error), InvalidState, ... }
struct Transaction { /* temp file, state */ }
impl Transaction {
fn new(path: &Path) -> Result { ... }
fn write(&mut self, data: &[u8]) -> Result { ... }
fn commit(self) -> Result { ... } // consume on success
fn rollback(mut self) { /* Drop реализует очистку */ }
}
Использование:
let mut tx = Transaction::new(path)?;
tx.write(&data)?;
tx.commit()?;
Часть C — эксперименты и сравнение
1. Показать примеры ошибок: I/O ошибка при записи, частичная запись, ошибочная последовательность вызовов (commit без записи), ресурсная утечка при исключении в Java и в Rust.
2. Для каждой реализации выполните:
- показать сигнатуры публичных методов и объяснить, как они документируют возможные ошибки;
- демонстрация пути успешного выполнения и путей обработки ошибок;
- показать, как происходит очистка ресурсов при ошибке (stack unwinding + finally vs Drop).
3. Провести простые тесты/сценарии отказа:
- симуляция частых/редких ошибок (внедрить искусственные ошибки), измерить поведение (корректность очистки, информация об ошибке).
- в критичной ситуации — показать реакцию: panics в Rust, unchecked exceptions в Java, отсутствие обработки в случае забытых catch/throws.
Часть D — анализ и выводы
Ответьте на вопросы:
- Как различия влияют на дизайн API? (явность ошибок в сигнатурах, богатство типов ошибок, композиция)
- Что удобнее для разработчика, что надёжнее для системы?
- Какой подход лучше подходит для критичных систем (например, авиация, медицина, оплата транзакций) и почему?
- Практические рекомендации: когда использовать checked exceptions, когда Result/Option, правила проектирования API (например, избегать unchecked исключений для ошибок, которые можно восстановить; в Rust — не злоупотреблять unwrap/panic в публичных API).
Ожидаемые результаты (deliverables)
- Репозиторий с двумя папками: java/ и rust/ с исходниками и тестами.
- Краткий отчёт (PDF или Markdown): 3–6 страниц с теоретическим сравнением, скриншотами/логами тестов, выводами и рекомендациями.
- Краткая презентация (5 слайдов): ключевые наблюдения и рекомендации.
Критерии оценки
- Правильность и полнота реализации (30%).
- Ясность API и соответствие идиомам языка (20%).
- Качество тестов и сценариев отказа (20%).
- Глубина анализа влияния на критичные системы, аргументация выводов (20%).
- Оформление репозитория и отчёта (10%).
Подсказки/замечания
- В Java аккуратно выбирайте между checked и unchecked exceptions; документируйте throws.
- В Rust моделируйте ошибки как enum с контекстом (используйте thiserror или anyhow для удобства, но объясните выбор).
- Сравнивайте не только синтаксис, но и эффекты на архитектуру: где ошибки «спрятаны», где они видны в типах.
- Для критичных систем отдавайте предпочтение явной обработке ошибок и детерминированной очистке ресурсов.
В конце — краткое резюме для включения в отчёт
- Java: удобство исключений для рантайм-ошибок, но риск скрытых ошибок и отсутствие гарантии обработки; finally/try-with-resources решают очистку.
- Rust: явные Result/Option делают ошибки видимыми в типах, помогают избежать незамеченных ошибок и повышают безопасность, RAII обеспечивает детерминированную очистку; panic — для неисправимых ситуаций.
- Рекомендация: для критичных систем лучше модель с явной проверкой ошибок (Result/Option или эквивалент), строгая типизация ошибок и детерминированная очистка; в Java — избегать необработанных unchecked exceptions и проектировать API с явными checked exceptions там, где восстановление возможно.
Если нужно, могу подготовить пример полностью реализованной мини-библиотеки и тестовый сценарий для обеих языков.