Лучшая практика для обработки ошибок в структуре `New ()`

Question

Дано:

type A struct{}

func New() *A {
  return &A{}
}

Какая рекомендация основана на лучшей практике для обработки ошибки, возникающей во время строительства?

Реальный сценарий построения time.Time для определенного time.Location на основе некоторого location string, который может быть недействительным.

EDIT:

Это больше, чем "если конструктор func вернет ошибку". Я хотел бы обсудить альтернативы.

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

Я хотел бы рассмотреть достоинства различных подходов.

РЕДАКТИРОВАТЬ 2:

Возможные подходы:

1. вернуть ошибку в конструкторе
2. только возвращает допустимую структуру и не допускает потенциально недопустимых параметров конструктора
3. возвращать экземпляр структуры nil при ошибке

РЕДАКТИРОВАТЬ 3:

Критерии рейтинга

1. Линии телефонного кода
2. Строки собственного кода
3. Уровень неопределенности

Answer 1

На основании голосов / комментариев, которые я вижу, я отвечу на это сам и закрою. Если кто-то хотел бы уточнить мой ответ, пожалуйста, прокомментируйте.

1) Вернуть ошибку в конструкторе

Плюсы

• Позволяет вызывающему коду иметь дело с меньшим количеством самой логики

Против

• Запрещает вызывающему коду выполнять встроенное присваивание, поскольку он возвращает несколько параметров.

2) Не разрешать потенциально недопустимые параметры конструктора

Например, не принимайте строковую дату, которую нужно разобрать в time.Time. Вместо этого требуется экземпляр time.Time в качестве параметра.

Плюсы

• Позволяет вызывающему коду выполнять встроенные назначения
• Включает нормальные значения по умолчанию

Против

• делает функцию конструктора менее удобной по сравнению с составным литералом
• Может потребоваться дополнительные отдельные удобные методы для структуры
• Требуется вызывающий код для обработки большей логики

3) Разрешить потенциально недопустимые параметры конструктора и использовать вместо них разумные значения по умолчанию

"отложить ошибку до следующей функции"

Плюсы

• Позволяет вызывающему коду выполнять встроенные назначения

Против * * тысяча пятьдесят-одна Трудно знать, были ли приняты желаемые параметры 4) Возвращать экземпляр структуры nil при ошибке Это возможно, но просто не очень хорошая идея. Кто-то даже сказал бы зло. Плюсы

• Разрешает встроенные назначения
• Позволяет вызывать код проще / наивнее

Против

• Не типичный (т.е. идиоматический) код Go
• Скрывает причину
• Позволяет вызывающему коду быть наивным