Comments 10
Как множатся стандарты
Очень надеюсь, что в Go 2 хотя бы частично будет решена вся эта чехарда с разными библиотеками для работы с ошибками
+5
Очень хорошо! Думаю, буду использовать.
В своем проекте решал с ошибками еще две проблемы, которые здесь не упомянуты:
1. Локализация текста ошибок;
2. При возникновении некоторых ошибок отправка нотификации о них на email.
В своем проекте решал с ошибками еще две проблемы, которые здесь не упомянуты:
1. Локализация текста ошибок;
2. При возникновении некоторых ошибок отправка нотификации о них на email.
0
Нотификации — строго говоря, ортогональный вопрос. Они могут работать по сообщениям в логе, через адаптеры, которые на определенные типы ошибок по конфигу генерируют сообщения, и множеством других способов. Сами ошибки — слишком низкоуровневый механизм, чтобы в нем хорошо смотрелась жесткая связь подобного рода.
Что же до локализации, то это часть вопроса представления ошибок, скажем, в API, который сам по себе сложный и довольно неприятный. С одной стороны, бизнес логика, откуда ошибки вылетают, не должна знать о таких вещах, как внешний API, в котором эти ошибки должны как-то трансформироваться и предоставляться наружу. С другой, работа с ошибками во внешнем API не должна быть хрупкой к изменениям на слое бизнес логики.
Есть примеры решений, когда, скажем, ошибка несет с собой HTTP status, который будет подложен в ответ. Мы считаем такое суровым нарушением абстракции и не допускаем, но, к сожеланию, эту проблему все равно приходится решать на каком-то уровне.
Что же до локализации, то это часть вопроса представления ошибок, скажем, в API, который сам по себе сложный и довольно неприятный. С одной стороны, бизнес логика, откуда ошибки вылетают, не должна знать о таких вещах, как внешний API, в котором эти ошибки должны как-то трансформироваться и предоставляться наружу. С другой, работа с ошибками во внешнем API не должна быть хрупкой к изменениям на слое бизнес логики.
Есть примеры решений, когда, скажем, ошибка несет с собой HTTP status, который будет подложен в ответ. Мы считаем такое суровым нарушением абстракции и не допускаем, но, к сожеланию, эту проблему все равно приходится решать на каком-то уровне.
0
По большому счету, с первым согласен. Однако, считаю что интеграция этого механизма в движок ошибок может существенно помочь разработчику.
На счет локализации то-же самое. Думаю, при таком построении механизма ошибок имеет смысл ее сделать интегрированно. Т.к., на мой взгляд, локализация тут впишется довольно гармонично.
Я вижу у вас лицензия MIT, так что я, вероятно, форкну ваш проект и добавлю все эти механизмы для собственного использования.
На счет локализации то-же самое. Думаю, при таком построении механизма ошибок имеет смысл ее сделать интегрированно. Т.к., на мой взгляд, локализация тут впишется довольно гармонично.
Я вижу у вас лицензия MIT, так что я, вероятно, форкну ваш проект и добавлю все эти механизмы для собственного использования.
+1
Подходов много, мне наиболее удобным и практичным показался такой вариант: создаём модуль/пакет debug с методом mypanic, принимающим error в качестве аргумента;
Данный метод через stdlib/reflect тянет актуальный stacktrace и выводит его с текстом error в stderr и/или пишет в лог.
Далее заменяем все panic на наш debug.panic и всё.
Подобный подход абсолютно идиоматичен для Go, так как ошибки остаются значениями, которые программист обязан обработать, при этом мы имеем минимум лишнего кода.
Данный метод через stdlib/reflect тянет актуальный stacktrace и выводит его с текстом error в stderr и/или пишет в лог.
Далее заменяем все panic на наш debug.panic и всё.
Подобный подход абсолютно идиоматичен для Go, так как ошибки остаются значениями, которые программист обязан обработать, при этом мы имеем минимум лишнего кода.
-1
Немного странный пример, есть же fmt.Errorf
return errors.New(fmt.Sprintf("failed to insert user %s: %v", u.Name, err)
0
Sign up to leave a comment.
Errorx — библиотека для работы с ошибками в Go