История изменений

Для меня выглядит довольно дико писать код, не думая об ошибках.

А для меня важно только то, чтобы ошибка аккуратно уронила нужный контекст (например текущий запрос), оставив систему в консистентном состоянии, просигнализировав кому положено о ситуации максимально подробно (например записав стек в логи и отдав HTTP 500). Это всё, о чём я думаю. И этого практически всегда хватает. Конечно бывают ситуации, когда действительно важно показать пользователю правильное сообщение об ошибке, когда важно обработать ошибку нетривиальным образом и тд и тп, но такие ситуации редки. А в коде безумное множество того, что может выдать ошибку в теории, но на практике не выдаст. И чуть меньше, но тоже много того, что ошибку изредка может выдать, но универсальной обработки для этой ошибки хватит за глаза. И пытаться обрабатывать все ошибки - верный способ написать уйму кода, который никто никогда не протестирует и который как раз совсем не факт, что в реальности сработает адекватно.

Собственно поэтому и в Go на практике чаще всего ошибки обрабатывают весьма похожим образом, передавая ошибку наверх, в идеале облепливая её дополнительной информацией и в конце концов обрабатывая её каким-то универсальным кодом. Это нормально. Ненормально только то, что синтаксис языка активно сопротивляется этой практике.

Я соглашусь лишь с тем, что значения локальных переменных, которые программист засунет в сообщение об ошибке, могут быть весьма полезными и в Java стектрейсах их может не хватать (хотя никто не мешает в Java писать ровно такой же код в уместных местах - ловить исключение и перевыбрасывать с дополнительной информацией).

errors.Wrapf

Что такое errors? Это This repository was archived?

Насколько я знаю, стандартный способ в Go нынче это fmt.Errorf в который вообще-то могли бы добавить информацию о стектрейсе, пускай даже включаемую через какой-нибудь ENV или ещё как-нибудь.

Для меня выглядит довольно дико писать код, не думая об ошибках.

А для меня важно только то, чтобы ошибка аккуратно уронила нужный контекст (например текущий запрос), оставив систему в консистентном состоянии, просигнализировав кому положено о ситуации максимально подробно (например записав стек в логи и отдав HTTP 500). Это всё, о чём я думаю. И этого практически всегда хватает. Конечно бывают ситуации, когда действительно важно показать пользователю правильное сообщение об ошибке, когда важно обработать ошибку нетривиальным образом и тд и тп, но такие ситуации редки. А в коде безумное множество того, что может выдать ошибку в теории, но на практике не выдаст. И пытаться обрабатывать все ошибки - верный способ написать уйму кода, который никто никогда не протестирует и который как раз совсем не факт, что в реальности сработает адекватно.

Собственно поэтому и в Go на практике чаще всего ошибки обрабатывают весьма похожим образом, передавая ошибку наверх, в идеале облепливая её дополнительной информацией и в конце концов обрабатывая её каким-то универсальным кодом. Это нормально. Ненормально только то, что синтаксис языка активно сопротивляется этой практике.

Я соглашусь лишь с тем, что значения локальных переменных, которые программист засунет в сообщение об ошибке, могут быть весьма полезными и в Java стектрейсах их может не хватать (хотя никто не мешает в Java писать ровно такой же код в уместных местах - ловить исключение и перевыбрасывать с дополнительной информацией).

errors.Wrapf

Что такое errors? Это This repository was archived?

Насколько я знаю, стандартный способ в Go нынче это fmt.Errorf в который вообще-то могли бы добавить информацию о стектрейсе, пускай даже включаемую через какой-нибудь ENV или ещё как-нибудь.