Чем меньше, тем лучше – согласен. Неосмотрительно – не согласен. Большая часть сайтов, любого масштаба, написана на интерпритируемых языках и, подозреваю, исходники вполне есть на проде.
Думаю, что гораздо быстрее и проще исходники можно получить через сотрудника или бывшего сотрудника.
Можно код написать и так, что любой `ioutil.ReadFile()` будет опасен.
И очевидно, я не сравниваю, что лучше, иметь или не иметь сорсы на проде, а сравниваю, покрывают ли приобретаемые бенефиты дополняющие их недостатки (например, в виде описанной Вами истории, где на сервере завелся хакер с доступом в систему). Если не покрывают (как, вероятно, в Вашем случае, поскольку Вам хватает просто правильно обрабатывать ошибки), то определенно не зачем их там держать.
В моем опыте не было ситуаций, когда компания, в которой я работал, переживала бы за то, чтобы держать исходники на своем собственно сервере.
Я не воспринимаю как обиду, спасибо, что уделили время и поделились своими мыслями.
Мне лично сорсы помогают добавить контекста к эррор-репорту, тем самым ускорить процесс понимания того, что пошло не так. Я допускаю, что не только мне одному. Если кому-то удобно получить стек трейс, затем идти по файлам, чтобы понять контекст, то pkg/errors подойдет гораздо лучше, я думаю.
Касательно юз-кейсов на проде, все то же самое – это добавляет контекста к ошибкам, не требует открывать код во многих случаях вообще, чтобы понять, в чем корень. Предлагаю посмотреть такие продукты, как: Sentry и Elastic APM. Они оба используют сорсы в стектрейсах, показывают сорсы и стектрейсы в ошибках, имеют овер 9000 поклонников, и указывают на своих сайтах сорсы в ошибках, как классную фичу: `Sentry shows your source code right in the stacktrace, so you don’t need to find it yourself.` Если этого не достаточно, то наверное, Вам это просто не нужно и у Вас нет такой проблемы.
То что нет проблем для себя это написать – у меня вот есть проблема писать для себя это каждый раз. Но нет проблемы написать 1 раз для себя и других.
Я думаю, leftpad (привет, npm) тоже нет проблемы написать для себя, или math.Round (привет, го 1.9) – тем не менее, многие этим не занимаются (как и я, в частности).
«Таких» это каких, которые отображают стектрейс и сорсы? Библиотека по ссылке, насколько я понимаю, может только стектрейс. Да, «таких» которые умею стектрейс полно, я не претендую на новизну)
Таких, которые отображают сорсы, я не встречал.
Тут не описывал, но можно получить оригинальную ошибку без стектрейса так: err.Err
Где обрабатывать ошибки, я не навязываю, как собственно и написал. Описанный способ подойдет для ошибок, которые пробрасываются наверх и для тех людей, кто считает это приемлимым.
В стектрейсе будет абсолютный путь до файла, где он был во время сборки. Там его будет искать этот пакет.
У меня есть план сделать, чтобы можно было подменять путь до $GOPATH, но пока не сделал.
Про парметр, как мне кажется, должны поддерживаться такие сценарии использования:
При чем тут первый день? Или во второй день он уже не джуниор?
В компаниях, которых я работал и работаю, так повелось, что баги исправляют разработчики, а не L3 саппорт / QA / бизнес аналитик (если они вообще есть в компании).
Unwrap()иError.Unwrap().Думаю, что гораздо быстрее и проще исходники можно получить через сотрудника или бывшего сотрудника.
Можно код написать и так, что любой `ioutil.ReadFile()` будет опасен.
И очевидно, я не сравниваю, что лучше, иметь или не иметь сорсы на проде, а сравниваю, покрывают ли приобретаемые бенефиты дополняющие их недостатки (например, в виде описанной Вами истории, где на сервере завелся хакер с доступом в систему). Если не покрывают (как, вероятно, в Вашем случае, поскольку Вам хватает просто правильно обрабатывать ошибки), то определенно не зачем их там держать.
В моем опыте не было ситуаций, когда компания, в которой я работал, переживала бы за то, чтобы держать исходники на своем собственно сервере.
Мне лично сорсы помогают добавить контекста к эррор-репорту, тем самым ускорить процесс понимания того, что пошло не так. Я допускаю, что не только мне одному. Если кому-то удобно получить стек трейс, затем идти по файлам, чтобы понять контекст, то pkg/errors подойдет гораздо лучше, я думаю.
Касательно юз-кейсов на проде, все то же самое – это добавляет контекста к ошибкам, не требует открывать код во многих случаях вообще, чтобы понять, в чем корень. Предлагаю посмотреть такие продукты, как: Sentry и Elastic APM. Они оба используют сорсы в стектрейсах, показывают сорсы и стектрейсы в ошибках, имеют овер 9000 поклонников, и указывают на своих сайтах сорсы в ошибках, как классную фичу: `Sentry shows your source code right in the stacktrace, so you don’t need to find it yourself.` Если этого не достаточно, то наверное, Вам это просто не нужно и у Вас нет такой проблемы.
Я думаю, leftpad (привет, npm) тоже нет проблемы написать для себя, или math.Round (привет, го 1.9) – тем не менее, многие этим не занимаются (как и я, в частности).
Таких, которые отображают сорсы, я не встречал.
Выше я описал привычное для Sprintf поведение, но по идее можно сделать разные методы.
err.ErrГде обрабатывать ошибки, я не навязываю, как собственно и написал. Описанный способ подойдет для ошибок, которые пробрасываются наверх и для тех людей, кто считает это приемлимым.
Бенчмарки на сравнение что с чем Вы предлагаете?
У меня есть план сделать, чтобы можно было подменять путь до $GOPATH, но пока не сделал.
Про парметр, как мне кажется, должны поддерживаться такие сценарии использования:
Как я понимаю, Вы имеете ввиду так?
Насчет и так и так, могу только согласиться. Пожалуй, надо добавить опциональным параметром.
И не относится к случаю в статье.
При чем тут первый день? Или во второй день он уже не джуниор?
В компаниях, которых я работал и работаю, так повелось, что баги исправляют разработчики, а не L3 саппорт / QA / бизнес аналитик (если они вообще есть в компании).