Обертывание ошибок
Есть три основных варианта распространения ошибок в случае сбоя вызова:
- Верните исходную ошибку, если нет дополнительного контекста для добавления и вы хотите сохранить исходный тип ошибки.
- Добавьте контекст, используя "github.com/pkg/errors".Wrap, чтобы сообщение об ошибке предоставляло больше контекста и "github.com/pkg/errors".Cause можно использовать для извлечения исходной ошибки.
- Используйте fmt.Errorf, если вызывающим абонентам не нужно обнаруживать или обрабатывать этот конкретный случай ошибки.
Рекомендуется добавлять контекст, где это возможно, чтобы вместо неопределенной ошибки, такой как "connection refused" ("соединение отклонено"), вы получали более полезные ошибки, такие как "call service foo: connection refused" ("вызов службы foo: соединение отклонено").
При добавлении контекста к возвращаемым ошибкам сохраняйте краткость контекста, избегая фраз вроде "failed to" ("не удалось"), которые констатируют очевидное и накапливаются по мере того, как ошибка просачивается через стек.
Менее удачный вариант:
s, err := store.New()
if err != nil {
return fmt.Errorf("failed to create new store: %s", err)
}
Вывод:
failed to x: failed to y: failed to create new store: the error
Более удачный вариант:
s, err := store.New()
if err != nil {
return fmt.Errorf("new store: %s", err)
}
Вывод:
x: y: new store: the error
Однако после отправки ошибки в другую систему должно быть ясно, что сообщение является ошибкой (например, тег err или префикс "Failed" в журналах).
Обработка ошибок утверждения типа
Форма единственного возвращаемого значения утверждения типа вызовет панику из-за неправильного типа. Поэтому всегда используйте идиому "comma ok".
Неудачный вариант:
t := i.(string)
Более удачный вариант:
t, ok := i.(string)
if !ok {
// корректно обрабатываем ошибку
}
Читайте также:
Комментариев нет:
Отправить комментарий