// гофер пытается найти логику среди обработки ошибок +-------+-------+-------+-------+-------+-------+ | | 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‑разработчиков, чем они живут, над какими задачами работают и где черпают полезную информацию о Go. В этом посте расскажем об основных инсайтах, а также узнаем, почему многие Go‑разработчики знают Python и мечтают выучить Rust. Читать далее