Как стать автором
Обновить

Комментарии 10

Как множатся стандарты

image


Очень надеюсь, что в Go 2 хотя бы частично будет решена вся эта чехарда с разными библиотеками для работы с ошибками

Очень хорошо! Думаю, буду использовать.

В своем проекте решал с ошибками еще две проблемы, которые здесь не упомянуты:
1. Локализация текста ошибок;
2. При возникновении некоторых ошибок отправка нотификации о них на email.
Нотификации — строго говоря, ортогональный вопрос. Они могут работать по сообщениям в логе, через адаптеры, которые на определенные типы ошибок по конфигу генерируют сообщения, и множеством других способов. Сами ошибки — слишком низкоуровневый механизм, чтобы в нем хорошо смотрелась жесткая связь подобного рода.

Что же до локализации, то это часть вопроса представления ошибок, скажем, в API, который сам по себе сложный и довольно неприятный. С одной стороны, бизнес логика, откуда ошибки вылетают, не должна знать о таких вещах, как внешний API, в котором эти ошибки должны как-то трансформироваться и предоставляться наружу. С другой, работа с ошибками во внешнем API не должна быть хрупкой к изменениям на слое бизнес логики.
Есть примеры решений, когда, скажем, ошибка несет с собой HTTP status, который будет подложен в ответ. Мы считаем такое суровым нарушением абстракции и не допускаем, но, к сожеланию, эту проблему все равно приходится решать на каком-то уровне.
По большому счету, с первым согласен. Однако, считаю что интеграция этого механизма в движок ошибок может существенно помочь разработчику.

На счет локализации то-же самое. Думаю, при таком построении механизма ошибок имеет смысл ее сделать интегрированно. Т.к., на мой взгляд, локализация тут впишется довольно гармонично.

Я вижу у вас лицензия MIT, так что я, вероятно, форкну ваш проект и добавлю все эти механизмы для собственного использования.
Подходов много, мне наиболее удобным и практичным показался такой вариант: создаём модуль/пакет debug с методом mypanic, принимающим error в качестве аргумента;
Данный метод через stdlib/reflect тянет актуальный stacktrace и выводит его с текстом error в stderr и/или пишет в лог.

Далее заменяем все panic на наш debug.panic и всё.

Подобный подход абсолютно идиоматичен для Go, так как ошибки остаются значениями, которые программист обязан обработать, при этом мы имеем минимум лишнего кода.
Немного странный пример, есть же fmt.Errorf
return errors.New(fmt.Sprintf("failed to insert user %s: %v", u.Name, err)


Согласен, но суть и проблема в нем те же.
Есть же вот либа, она всё это, что вы рассказали, более или мене позволяет делать. И стектрейс там есть, и унаследованные ошибки.
Эта библиотека хороша, безусловно. Отличие в том, что она минималистична, тогда как errorx богаче в плане фичей и «из коробки» позволяет решать больше задач. И тот, и другой подход обладают своей привлекательностью.

Спасибо за ответ, согласен с Вашими оценками

Зарегистрируйтесь на Хабре, чтобы оставить комментарий