Телеграмм чат группы gogolang страница 19258

Да, я про то же, как правило, причина важна для того чтобы потом понять что реально случилось, а "контекст" (Сообщение сверху), важно отдать пользователю, при этом не вскрывая детали которые пользователь все равно не поймет (а иногда и знать не должен). И как в этом случае быть с этой фунцкиией? Она кажется не решает эту проблему совсем. Кажется эту функцию есть смысл использовать только в том случае, когда важна ошибка внутри %w и ее позже хочется вытащить и че то с ней сделать.

Так выше, когда мы через Is/As обёрнутую ошибку проверяем, мы же её с конкретной ошибкой сравниваем.
Ну вот если сравнение успешно, то ту, с которой сравнивали, отдаём пользователю, а ту которую сравнивали, пишем в лог (или что-то ещё делаем)

UPD: неправильно понял вопрос. Всё, что написал, мимо
UPD2: или правильно понял

источник

15:24пожаловаться #5

x

x-foby in Go-go!

@antonikucherov вы об этом?
https://play.golang.org/p/2ZzTJN6N0Jw

источник

15:30пожаловаться #6

AK

Anton Kucherov in Go-go!

x-foby

Так выше, когда мы через Is/As обёрнутую ошибку проверяем, мы же её с конкретной ошибкой сравниваем.
Ну вот если сравнение успешно, то ту, с которой сравнивали, отдаём пользователю, а ту которую сравнивали, пишем в лог (или что-то ещё делаем)

UPD: неправильно понял вопрос. Всё, что написал, мимо
UPD2: или правильно понял

Вот есть у меня 1 юзкейс: Я меняю у пользователя описание профиля.
У меня есть 2 "бизнесовых" ошибки (Причины каждой могут быть совершенно разные, от опечатки в имени пользователя до падения БД):

var err error // Reason. More specific error. Database error for example.
wrongUserEmail := fmt.Errorf("Can't get specified user, reason: %w", err)
saveProfileInfoError := fmt.Errorf("Can't save profile info, reason: %w", err)

Как мне теперь отдать 400 если ошибка произошла на этапе валидации. Не важно по какой именно причине (wrongUserEmail)
И как отдать 500 если ошибка произошла на этапе сохранения. Опять же причина дял пользователя не важна (saveProfileInfoError)?
Причина важна для меня как для программиста. Я не хочу пользователю сообщать детали. Я пользователю хочу отдать понятное ему сообщение без деталей. А сообщение целиком записать в лог.

источник

15:41пожаловаться #7

AK

Anton Kucherov in Go-go!

Как я понял, эта функция fmt.Errorf вообще для этого не подходит. Нужно использовать кастомные типы ошибок. А у этой функции очень узкое назначение по сути...?

источник

15:42пожаловаться #8

PV

Pavel Vorontsov in Go-go!

всем привет!
есть ли разница между

a := struct{}
doFunc(&a)

и

a := &struct{}
doFunc(a)

источник

15:42пожаловаться #9

ВС

Владимир Столяров... in Go-go!

Anton Kucherov

Вот есть у меня 1 юзкейс: Я меняю у пользователя описание профиля.
У меня есть 2 "бизнесовых" ошибки (Причины каждой могут быть совершенно разные, от опечатки в имени пользователя до падения БД):

var err error // Reason. More specific error. Database error for example.
wrongUserEmail := fmt.Errorf("Can't get specified user, reason: %w", err)
saveProfileInfoError := fmt.Errorf("Can't save profile info, reason: %w", err)

Как мне теперь отдать 400 если ошибка произошла на этапе валидации. Не важно по какой именно причине (wrongUserEmail)
И как отдать 500 если ошибка произошла на этапе сохранения. Опять же причина дял пользователя не важна (saveProfileInfoError)?
Причина важна для меня как для программиста. Я не хочу пользователю сообщать детали. Я пользователю хочу отдать понятное ему сообщение без деталей. А сообщение целиком записать в лог.

вот в таком случае как раз лучше пользоваться типами

источник

15:43пожаловаться #10

ss

santiago s in Go-go!

Anton Kucherov

Как я понял, эта функция fmt.Errorf вообще для этого не подходит. Нужно использовать кастомные типы ошибок. А у этой функции очень узкое назначение по сути...?

да, fmt.Errorf не для этого, она скорее для кейсов типа: есть у вас функция myFunc которая возвращает ошибку myError
и функция эта может быть вызвана в трех местах, вот чтобы понять цепочку вызовов, вы используете fmt.Errorf

источник

15:44пожаловаться #11

AK

Anton Kucherov in Go-go!

Владимир Столяров

вот в таком случае как раз лучше пользоваться типами

Вот я тоже к этому пришел, причем это как правило наиболее частый случай. Ну из моего опыта. Т.е. когда при обработке пользователю хочешь сообщить одно, а в лог записать другое. Я понимаю, записать в лог это уже обработка, но часто хочется еще и пользователю отдать полезную инфу, в зависимости от того, что конкретно произошло.

источник

15:44пожаловаться #12

AK

Anton Kucherov in Go-go!

santiago s

да, fmt.Errorf не для этого, она скорее для кейсов типа: есть у вас функция myFunc которая возвращает ошибку myError
и функция эта может быть вызвана в трех местах, вот чтобы понять цепочку вызовов, вы используете fmt.Errorf

🤔 Спасибо, подумаю над этим.

источник

15:45пожаловаться #13

ВС

Владимир Столяров... in Go-go!

кстати лайфхак: можно завести вот такой интерфейс

type HTTPError interface{
  error
  Code() int
  ReturnText() string
}

и в обработчиках проверять по errors.As на него, прокидывая текст и код в ответ прямо оттуда

источник

15:46пожаловаться #14

ВС

Владимир Столяров... in Go-go!

и во всяких бизнес-ошибках его реализовывать, а по-умолчанию например кидать 500

источник

15:46пожаловаться #15

x

x-foby in Go-go!

Anton Kucherov

Вот есть у меня 1 юзкейс: Я меняю у пользователя описание профиля.
У меня есть 2 "бизнесовых" ошибки (Причины каждой могут быть совершенно разные, от опечатки в имени пользователя до падения БД):

var err error // Reason. More specific error. Database error for example.
wrongUserEmail := fmt.Errorf("Can't get specified user, reason: %w", err)
saveProfileInfoError := fmt.Errorf("Can't save profile info, reason: %w", err)

Как мне теперь отдать 400 если ошибка произошла на этапе валидации. Не важно по какой именно причине (wrongUserEmail)
И как отдать 500 если ошибка произошла на этапе сохранения. Опять же причина дял пользователя не важна (saveProfileInfoError)?
Причина важна для меня как для программиста. Я не хочу пользователю сообщать детали. Я пользователю хочу отдать понятное ему сообщение без деталей. А сообщение целиком записать в лог.

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

источник

15:48пожаловаться #16

RS

Roman Sharkov in Go-go!

Anton Kucherov

Вот есть у меня 1 юзкейс: Я меняю у пользователя описание профиля.
У меня есть 2 "бизнесовых" ошибки (Причины каждой могут быть совершенно разные, от опечатки в имени пользователя до падения БД):

var err error // Reason. More specific error. Database error for example.
wrongUserEmail := fmt.Errorf("Can't get specified user, reason: %w", err)
saveProfileInfoError := fmt.Errorf("Can't save profile info, reason: %w", err)

Как мне теперь отдать 400 если ошибка произошла на этапе валидации. Не важно по какой именно причине (wrongUserEmail)
И как отдать 500 если ошибка произошла на этапе сохранения. Опять же причина дял пользователя не важна (saveProfileInfoError)?
Причина важна для меня как для программиста. Я не хочу пользователю сообщать детали. Я пользователю хочу отдать понятное ему сообщение без деталей. А сообщение целиком записать в лог.

ErrInvalidUsername = errors.New(“invalid username“)

func ValidateUsername(s string) error {
  if s == “” {
    return ErrInvalidUsername
  }
  return nil
}

func Foo(username string) error {
  if err := Bar(); err != nil {
    return fmt.Errorf(“executing bar: %w”, err)
  }
  if err := ValidateUsername; err != nil {
    return fmt.Errorf(“validating username: %w”, err)
  }
  return nil
}

func HandleRequest() {
  err := Foo(“newUsername”)
  switch {
  case errors.Is(err, ErrInvalidUsername):
    return 400
  case err != nil:
    return 500
  }
  return 200
}