// гофер пытается найти логику среди обработки ошибок +-------+-------+-------+-------+-------+-------+ | | err | | err | | err | | ,_,,, | | | | | | (◉ _ ◉) | | | | | | /) (\ | | | | | "" "" | | | | + +-------+ +-------+ +-------+ | | err | err | | err | | | | | | | | | | | | | +-------+ +-------+ +-------+ + | err | | err | | | | | | | | | + +-------+ + +-------+ + | | err | | err | logic | | | | | | | | | | | | |…
Программисты на Go уже давно и долго жалуются на слишком многословную обработку ошибок. Все мы близко (а иногда и болезненно) знакомы со следующим шаблоном кода:x, err := call()if err != nil { // обработка err}Проверка if err != nil встречается настолько часто, что может становиться объёмнее…
Каждый Go-разработчик знаком с этим паттерном — создание обёрток для ошибок с дублированием метаданных: func (*SomeObject).SomeMethod(val any) error { if err := otherMethod(val); err != nil { return fmt.Errorf("otherMethod %w with val %v", err, val) } return nil } Проблемы такого подхода: Дублирование названий методов в сообщениях об ошибках…
Привет, Хабр! Меня зовут Павел Агалецкий, я ведущий инженер в платформе Авито. Эта статья на одну из самых холиварных тем, о которой вы могли слышать или читать множество раз. При обсуждении Go, особенно новичками или представителями других языков программирования, камнем…