Лучшая практика для значений результата при возврате ошибки в Go - PullRequest
0 голосов
/ 07 февраля 2019

Если ваша функция возвращает как тип значения, так и тип ошибки, действительно ли это "ход", чтобы убедиться, что тип значения имеет нулевое / нулевое значение, если тип ошибки не ноль?

Пример:

func mayError() ([]string, error) {
  ...
}

Если возвращаемое значение []string будет nil, если error не nil?

1 Ответ

0 голосов
/ 07 февраля 2019

Вообще говоря, если функция не выполнила задачу, ее возвращаемое значение следует рассматривать как ненадежное.Поскольку ошибки в go являются значениями, вызывающая сторона может игнорировать возвращаемую ошибку.Например:

foo := myType{
    Bar: 123,
    Foo: "some string",
}

b, _ := json.Marshal(foo)

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

slice, _ := mayError()

И ваша функция после добавления 2-х элементов к срезу выдает ошибки.Возврат частичного среза может и, вероятно, приведет к некорректному поведению в дальнейшем.Это затрудняет отладку кода.В целом, я бы сказал, что в этом случае лучше вернуть нулевой срез и ошибку.Если код выглядит следующим образом:

slice, _ := mayError() // returns nil, someErr
// panic
if slice[0] != "" {
}

По крайней мере, ошибка появляется немедленно, и вы увидите, что любые ошибки, возвращаемые mayError, игнорируются.Это облегчает отладку, поддержку и исправление кода.

Добро пожаловать на сайт PullRequest, где вы можете задавать вопросы и получать ответы от других членов сообщества.
...