Очередная дискуссия про обработку ошибок в Go

https://habr.com/ru/companies/karuna/articles/830346/

Пост написан по мотивам поста этого же автора в его Telegram-канале.

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

Если ты новичок, можешь погрузиться в тему - что же у нас не так с обработкой ошибок. А если опытный разработчик, можешь в очередной раз присоединиться к дискуссии и почитать proposals 🍾

————

Сам я выкручиваюсь обычно так:

func myFunc() error {
    const op = "mypackage.myFunc"
    // ...
    if err != nil {
        return fmt.Errorf("%s: %w", op, err)
    }

Не идеально, но просто и понятно.
Надеюсь, что когда-нибудь авторы предложат нам что-то более удобное.

#error_handling

Регламент для работы с ошибками в Go

https://habr.com/ru/companies/oleg-bunin/articles/913096/

Ну что, готовы в очередной раз обсудить работу с ошибками? 😩

#article #error_handling

Golang тихо умирает? 🙅‍♂️

- Перевод
- Оригинал (недоступен: This account is under investigation or was found in violation of the Medium Rules)

Автор статьи заявляет, что крупные компании начали "тихий отказ" от Go в пользу Rust, Kotlin и TypeScript.

Причины:

- Простота языка 👍
- Непредсказуемые паузы из-за GC 💪
- Бедность абстракций и неудобная обработка ошибок 😩

В качестве примеров приводятся Cloudflare, Dropbox и Amazon, которые частично заменили Go на Rust.

————

Звучит страшновато, конечно. Но есть нюанс: примеры автора выглядят скорее как исключения и диверсификация, а не отказ. Cloudflare и Dropbox переписали лишь части проектов, а вся остальная инфраструктура и дальше спокойно живёт на Go. Сами же Google, AWS и куча других активно инвестируют в язык, а сообщество стабильно растёт.

Да, Go отдал Rust-у узкую нишу «real-time без GC». И это логично — нельзя идеально закрывать сразу все сценарии. Но говорить про смерть Go рановато (и даже смешно): тот же Docker, K8s, Terraform, Grafana, Prometheus и весь облачный стек чувствуют себя отлично и никуда не собираются.

Ну и вот эта цитата особенно забавляет: ... Но эпоха, когда Go был будущим программирования? Она угасает.

А что, кто-то считал Go "будущим программирования"? 🙃

Итого: языки не умирают так просто. Сколько лет уже хоронят Java и PHP?

#article #error_handling

if err != nil: почему мы (не) любим обработку ошибок в Go? Обзор предложений по её улучшению

https://habr.com/ru/companies/avito/articles/944824/

Павел Агалецкий из Авито в очередной раз поднимает вечную холиварную тему — обработку ошибок в Go.

Суть проблемы (а вдруг кто-то не в курсе? 🙃):

Go не использует исключения (exceptions) — ошибки это просто значения, которые функции возвращают наравне с другими. Код выглядит многословно:

func doSomething() error {
    if err := one(); err != nil {
        return err
    }
    if err := two(); err != nil {
        return err
    }
    if err := three(); err != nil {
        return err
    }
    return nil
}

Сравнение с другими языками:

- Python — исключения есть, но из сигнатуры непонятно, выбрасывает метод исключение или нет
- Java — есть checked exceptions, но большинство функций в языке и библиотеках их не декларируют, т.к. это необязательно
- Rust — есть тип Result<T, E> и оператор ? для проброса ошибок (более компактно)

Что было предложено за годы существования Go:

На GitHub 195 закрытых и 14 открытых proposal по улучшению обработки ошибок. Автор группирует их:

1. check/handle — специальные ключевые слова, чтобы обрабатывать ошибки единообразно
2. try/catch — как в других языках
3. Спецсимволы (? или !) — вместо ключевых слов
4. Упрощение if — тернарные операторы и подобное

Все отклонялись по схожим причинам:
- Можно частично реализовать в userland (через panic/recover + defer)
- Ломается при оборачивании ошибок (fmt.Errorf)
- Появляется неявный control flow
- Код становится менее читаемым

Последний proposal от Ian Lance Taylor:

Ян предложил писать знак вопроса после функций, возвращающих ошибки:

func doSomething(in Dto) (err error) {
    validate(in) ?
    one() ?
    two() ?
    three() ?
    return nil
}

С возможностью обработки:

validate(in) ? {
    return fmt.Errorf("validation failed: %w", err)
}

Реакция сообщества неоднозначная, больше против. Дизлайков в полтора раза больше лайков.

Финал истории:

Robert Griesemer опубликовал статью в блоге Go, где команда объявила, что они больше не будут рассматривать предложения по изменению обработки ошибок. Решили, что на этапе создания языка стоило подумать лучше, но сейчас менять поздно — будет только хуже.

————

Автор делает правильные выводы:
Ошибки как обычные значения — это нормально, явная сигнатура — это хорошо, отсутствие исключений — это прекрасно. Да, многословно, но явно. Да, занимает много места, но зато всё понятно. А современные IDE с autocomplete (особенно с LLM) и code folding помогают справляться с многословностью (у меня в IDE вообще давно настроен хоткей для создания error handling блока: CMD + J).

Я полностью согласен. Лучше писать чуть больше, но понимать что происходит, чем получить "волшебный" синтаксис, который будет работать неявно. Go Team приняли мудрое решение — оставить всё как есть. Язык не должен становиться зоопарком из разных способов сделать одно и то же.

Да, в первые годы работы с Go мне тоже хотелось всячески его "облагородить", изобретать разные способы "упрощения" работы с ошибками, но со временем это проходит 🙃

P.S. Мне кажется, что все эти годы сообщество пытается запихнуть в Go механики из других языков, вместо того чтобы просто принять философию Go 🤡

#article #error_handling #proposals