Size: a a a

2020 April 26

i

inqfen in Go-go!
И очевидное решение не всегда с точки зрения языка кошерное
источник

AS

Alexandr Sokolov in Go-go!
inqfen
И очевидное решение не всегда с точки зрения языка кошерное
Это больше вопрос кодстайла. В данном случае я бы предпочел сделать так


vals := make(map[type]type)

val, err := getVal()
if err != nil {
...
}

vals["key"] = val


Это прозрачно
источник

i

inqfen in Go-go!
Ну вот я к тому же, то ли err объявлять, то ли через промежуточную переменную делать
источник

а

а кто это in Go-go!
Alexandr Sokolov
Это больше вопрос кодстайла. В данном случае я бы предпочел сделать так


vals := make(map[type]type)

val, err := getVal()
if err != nil {
...
}

vals["key"] = val


Это прозрачно
можно сделать через if-else, тогда еще и пространство имен не будет засрано
источник

AS

Alexandr Sokolov in Go-go!
Плюс в пользу решения выше: если функция вернет отшибку, то вы запишите в мапу невалидное значение, что может поломать вашу бизнес логику, если эта мапа используется где-то еще
источник

а

а кто это in Go-go!
а кто это
можно сделать через if-else, тогда еще и пространство имен не будет засрано
vals := make(map[type]type)


if val, err := getVal(); err != nil {
...
} else {
 vals["key"] = val
}
источник

i

inqfen in Go-go!
Alexandr Sokolov
Плюс в пользу решения выше: если функция вернет отшибку, то вы запишите в мапу невалидное значение, что может поломать вашу бизнес логику, если эта мапа используется где-то еще
Если ошибка, exit(1)
источник

i

inqfen in Go-go!
Дальше имеет смысл только показать ошибку и выйти
источник

AS

Alexandr Sokolov in Go-go!
inqfen
Если ошибка, exit(1)
А вот так в продакшн коде вообще делать не нужно ни при каких обстоятельствах)
источник

i

inqfen in Go-go!
А что неправильного в выходе с exit кодом не 0 при ошибке?
источник

AS

Alexandr Sokolov in Go-go!
inqfen
А что неправильного в выходе с exit кодом не 0 при ошибке?
Ваше приложение падает при ошибке. Ошибки нужно обрабатывать, а не падать

Единственое, когда это действительно оправдано (исключая всякие паники) - при старте приложения, если никак не получается получить необходимые ресурсы (база лежит например), и делать это стоит только в main функции, чтобы не было неожиданностей для тех, кто будет работать с этим кодом после вас
источник

i

inqfen in Go-go!
Ну в данном случае - оно должно упасть, потому что у инстанса нет определенных вещей в метадате, либо метадата недоступна, причем должно упасть с читаемой ошибкой и exit code != 0, так как он должен быть обработан башем, это часть старта инстанса
источник

i

inqfen in Go-go!
  instanceParams["instance-id"], err = client.GetMetadata("instance-id")
 if err != nil {
   fmt.Println(err)
   os.Exit(1)
 }
 instanceParams["public-ip"], err = client.GetMetadata("public-ip")
 if err != nil {
   fmt.Println(err)
   os.Exit(1)
 }


При наличии любого из err дальшейшая работа не нужна, нужно выплюнуть ошибку и упасть
источник

i

inqfen in Go-go!
В дальнейшем exit code будет обработан уже башем, в разных сценариях падения возможно будут разные exit code
источник

а

а кто это in Go-go!
все равно не очень красиво
источник

i

inqfen in Go-go!
Ну как у того же пинга например, недоступность хоста и отсутствие маршрута - exit code разные
источник

а

а кто это in Go-go!
можно сделать run() error, который будет возвращать ошибки, и main(), который будет их правильно обрабатывать в одной точке
источник

i

inqfen in Go-go!
а кто это
можно сделать run() error, который будет возвращать ошибки, и main(), который будет их правильно обрабатывать в одной точке
В смысле != nil {
 errorHandler(err)
}
источник

а

а кто это in Go-go!
в смысле вы возвращаете ошибку в run
и только в main err != nil
источник

а

а кто это in Go-go!
можно использовать errors.Is
можно использовать свою ошибку
источник