Comments 9
требует больших проверок, но ведет к более надежному коду
Или не ведёт, потому что в сотый раз писать if err != nil уже надоело, но ты на автомате это вынужден делать и есть большой шанс профукать важную ситуацию
Вообще про сотый раз это часть правды, по крайней мере чисто по ощущениям. Довольно часто приходится добавлять какую-то уникальную логику в обработку ошибок (например, по разному реагировать на разные ошибки). Иногда обработка может вообще в отдельный defer блок уйти (такое можно увидеть в http ручках). Ну и в конце-концов их gopls через раз, но всё-таки предлагает написать if err != nil код комплишеном ))
зачем писать самому если копилот пишет сам?))
К надежному и красивому коду ведет концепция let it crash и супервизоры в Эликсир / Эрланг + паттерн-матчинг.
Где-то читал историю создания языка Го и кажется исключений там нет только потому что тогда их еще не придумали )
Ну исключения по идее очень старая вещь, так что они точно знали ). К тому же в языке есть похожий на исключения механизм через panic defer recover.
Ага, изучите историю языка.
https://youtu.be/ql-uncsqoAU?si=8_kk2E1D3J9q2OXn
Это все не гугл придумал.
50+ минут изучать видео по поводу вашего тейка об эксепшнах? Хотя бы таймкод указали...
А вообще есть официальный ответ в FAQ по этому поводу – Why does Go not have exceptions?
Хорошая статья. Написана, по ощущениям, для новичков, так как часто упоминаются довольно простые истины, например "самая базовая практика — никогда не игнорировать ошибки". Прочитав главу за главой, у меня периодически возникало ощущение недосказанности... Убедительная просьба к автору:
Дописать хотя бы один пример вывода цепочки ошибок с
%wДля кастомной ошибки дописать пример метода
Unwrap()
Ошибки в Go: Обработка, Обертки и Лучшие Практики