Golang: Главная проблема в Обработке Ошибок! #golang #go

🔥 https://t.me/+RAiQoS5k4Bg4NGYy – огромное количество уроков, библиотек и примеров с кодом в канале для Go разработчиков. 📌 https://t.me/addlist/MUtJEeJSxeY2YTFi – тут я собрал гигантскую папку маст-хэв для Golang программистов. 📌 https://t.me/golang_interview - здесь разобрано 1900 вопросов с собеседований GO Проблема — Многословность Обработки Ошибок Основная и наиболее давняя жалоба на Go касается многословности (verbosity) обработки ошибок. Программисты очень хорошо знакомы с паттерном кода: x, err := call() if err != nil { // handle err }. Тест if err != nil настолько распространен, что он часто "заглушает остальную часть кода". Например, в функции, состоящей из десяти строк, шесть строк могут восприниматься как "шум" или избыточный код, в то время как только четыре строки выполняют "реальную работу". Эта проблема годами возглавляла ежегодные опросы пользователей Go. Попытки Найти Синтаксическое Решение Команда Go серьезно отнеслась к обратной связи и в течение многих лет пыталась найти решение. Было предпринято три основных попытки: 1. Механизм check и handle (2018): Этот подход был признан слишком сложным. 2. Предложение try (2019): Упрощенная версия check/handle, где check стал встроенной функцией try. Это предложение было интенсивно обсуждалось (около 900 комментариев), но было отклонено, поскольку try изменял поток управления, возвращая управление из функции в случае ошибки, даже из глубоко вложенных выражений, что делало этот поток скрытым и "неприятным для многих". 3. Использование оператора ? (2024): Идея была заимствована из языка Rust. В небольших неформальных исследованиях пользователи в основном правильно угадывали значение этого синтаксиса. Однако и это предложение не смогло получить широкой поддержки. В общей сложности, ни одно из трех полноценных предложений от команды Go, ни сотни (!) предложений от сообщества, не смогли собрать достаточной (или подавляющей) поддержки. Окончательное Решение Команды Go Команда Go приняла прагматичное решение, заключающееся в следующем: прекратить попытки решить синтаксическую проблему обработки ошибок, по крайней мере, в обозримом будущем. Обоснование этого решения: • Отсутствие консенсуса: Цель процесса предложения (proposal process) — достичь общего консенсуса. Поскольку ни одно из предложений по обработке ошибок не приблизилось к консенсусу, все они были отклонены. Даже самые высокопоставленные члены команды Go не пришли к единому мнению относительно наилучшего пути вперед. • Идиоматичность: Go существует уже 15 лет, и возможность ввести синтаксический сахар на ранних этапах упущена. Если сейчас добавить новый синтаксис, он, в отличие от дженериков, которые можно игнорировать, почти наверняка станет обязательным для написания идиоматического кода, что вызовет недовольство у тех, кто предпочитает существующий статус-кво. • Соответствие принципам дизайна: Не добавлять синтаксис соответствует одному из правил дизайна Go: не предоставлять несколько способов сделать одно и то же. • Помощь в отладке: Существующая конструкция if полезна для отладки, так как позволяет легко добавить println или установить точку останова. Скрытые конструкции типа check, try или ? усложнили бы отладку. • Обратная связь: Некоторые недавние опросы пользователей (Google Cloud Next 2025) показали, что опытные пользователи Go считают, что проблему наименее заметна, как только разработчик становится более беглым и пишет более идиоматичный код на Go. Команда Go сосредоточится на других возможностях улучшения языка. Они также отмечают, что многословность уменьшается, когда ошибки действительно обрабатываются хорошо, например, путем добавления контекстной информации (повышая полезность ошибок), и благодаря новым функциям стандартной библиотеки, таким как cmp.Or. В связи с этим решением, команда Go также закроет все открытые и входящие предложения, которые касаются преимущественно синтаксиса обработки ошибок, без дальнейшего расследования #голанг микросервисы, API, REST, gRPC, concurrency, goroutines, channels, Go модули, Go compiler, стандартная библиотека, net/http, JSON, базы данных, PostgreSQL, MongoDB, SQL, ORM, GORM, тестирование, TDD, профилирование, производительность, контейнеризация, Docker, Kubernetes, CI/CD, DevOps, Cloud Native, AWS, Azure, GCP, Gin, Echo, Fiber, фреймворки, open source, сообщество, GoLand