// гофер пытается найти логику среди обработки ошибок +-------+-------+-------+-------+-------+-------+ | | err | | err | | err | | ,_,,, | | | | | | (◉ _ ◉) | | | | | | /) (\ | | | | | "" "" | | | | + +-------+ +-------+ +-------+ | | err | err | | err | | | | | | | | | | | | | +-------+ +-------+ +-------+ + | err | | err | | | | | | | | | + +-------+ + +-------+ + | | err | | err | logic | | | | | | | | | | | | |…
Если загуглить «как посчитать вовлечённость», все источники говорят одно и то же. Реакции поделить на охват, умножить на сто. Это и есть ERR. Формулу повторяют десятки статей и любая нейросеть. Чего не делает почти никто, так это не объясняет, как потом эту цифру читать. А там начинается самое интересное, потому что у метрики есть пара неочевидных свойств, из‑за которых выводы на ровном месте получаются неверными. Читать далее
Программисты на 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 } Проблемы такого подхода: Дублирование названий методов в сообщениях об ошибках…