Кратко о подходах (влияние на читаемость и надёжность):
- Исключения (Java/Python)
- Плюсы: убирают «шум» явной передачи ошибок, код основного потока чище; позволяют централизованную обработку и откат (stack unwinding).
- Минусы: контроль потоков ошибок неявен — легко пропустить обработку; могут скрывать «скрытые» ветви исполнения; в крупных системах требуют дисциплины (чёткие контракты/документация по исключениям).
- Надёжность: зависит от того, где ловят исключения; необработанные — аварийное завершение.
- Возвращаемые ошибки (Go)
- Плюсы: явное управление — каждый вызов виден; простой, предсказуемый контроль потока.
- Минусы: многословность, шаблон «if err != nil» может ухудшать читаемость; без соглашений можно терять контекст ошибки.
- Надёжность: высокая при дисциплинированной обработке и оборачивании ошибок (wrapping) для контекста; удобно для ясного, локального управления ошибками.
- Result / Option (Rust)
- Плюсы: компилятор принуждает обрабатывать результат; удобные операторы (`?`) и композиция; типы ошибок/вариантов явны, можно паттерн‑матчить.
- Минусы: требует привыкания к монодической обёртке; в простых случаях чуть более многословно, чем исключения.
- Надёжность: очень высокая — ошибки трудно «забыть» обработать.
- Either / типы в функциональных языках
- Плюсы: явное представление успеха/ошибки, легко комбинировать через монады/функторы; хорошая композиция и тестируемость.
- Минусы: похожи по шаблону на Result; иногда громоздки без языковой поддержки (синтаксического сахара).
- Надёжность: высокая при строгой типизации и использовании combinators.
Сравнительная заметка:
- Исключения дают лаконичность, но скрывают контроль потока; подходят для приложений, где ошибки действительно исключительны.
- Явные возвращаемые ошибки (Go) и Result/Option (Rust) делают обработку видимой и проверяемой; Rust сочетает безопасность типов с удобством (`?`), Go — простоту и предсказуемость.
- Для библиотек лучше явные ошибки (передача назад) + оборачивать контекст; для приложений допустимы фатальные завершения на верхнем уровне.
Почему приведённый Go‑код плохой стиль:
```go
func readFile() ([]byte, error) {
data, err := ioutil.ReadFile("f")
if err != nil {
panic(err)
}
return data, nil
}
```
Проблемы:
- `panic` завершит программу (stack unwind) и не даст вызывающему коду возможности обработать ошибку — недопустимо для библиотечных функций.
- Использование `ioutil` устарело (deprecated с Go $1.16$); лучше `os.ReadFile`.
- Нет контекста в ошибке (какой файл, что произошло).
- Функция заявляет возвращаемую ошибку, но фактически никогда её возвращает — вводит в заблуждение.
Как улучшить (лучший стиль для библиотеки):
```go
func readFile(path string) ([]byte, error) {
data, err := os.ReadFile(path)
if err != nil {
return nil, fmt.Errorf("read file %q: %w", path, err)
}
return data, nil
}
```
Пояснения:
- Передаём путь как параметр — функция становится переиспользуемой.
- Возвращаем ошибку вызывающему вместо `panic`.
- Оборачиваем ошибку с контекстом и `%w`, чтобы можно было использовать `errors.Is`/`errors.As`.
Если функция используется только в init/main и на ошибке нужно аварийно завершиться (тогда уместен `log.Fatal` или `panic`, но на самом верхнем уровне), пример:
```go
func mustReadFile(path string) []byte {
data, err := os.ReadFile(path)
if err != nil {
log.Fatalf("cannot read file %q: %v", path, err)
}
return data
}
```
Вывод-руководство:
- В библиотечном коде возвращайте и оборачивайте ошибки.
- Используйте `panic`/`log.Fatal` только для действительно фатальных ситуаций на верхнем уровне или в тестах/инициализации.
- Добавляйте контекст ошибки для диагностики; применяйте `errors.Is`/`errors.As` для распознавания типов ошибок.