Comments 4
А точно ли на неверный код ответа надо кидать панику?
Обертка через fmt.Errorf - редкостная гадость, потому что на верхних уровнях (грпц интерсептор, например) через errors.As/Is получится достать только исходную ошибку, но никак не контекст. Для нормального оборачивания есть errors.Join и "константные" ошибки слоя
Вот где вы написали про "Когда оборачивать ошибку не лучшая идея"
По сути все в том, что изменился тип ошибки (как вы и написали) и вызывающий код теперь ничего не знает о том, что возвращается.
Но! Это (кмк) не проблема - потому что раз ошибка поменялась, значит и реакция должна поменяться, если же это не так, то скорее всего надо делать ошибку более общую (тогда и менять ее не надо) - например ValidateError.
Поэтому тут особой проблемы я не вижу (если работать через As также)
В общем, я не совсем понял в том месте вашу идею и мысль.
Не могу определиться что меня раздражает сильнее : кривая обработка ошибок в Go или статьи об этом на Хабре раз в два дня.
В целом ок, читается легко, стиль живой — за это плюс. Но по содержанию, если честно, немного сыровато. Не хватило глубины и реальных примеров. Типа окей, мы поняли общую идею, а что дальше?
Было бы круто, если бы добавил какие-нибудь техподробности:
– чем конкретно мониторишь (Prometheus, Zabbix, что-то кастомное?)
– как строишь алерты — руками или есть шаблоны?
– как борешься с ложными срабатываниями?
– есть ли логика auto-remediation?
Обработка ошибок в Go