Соглашение по обработке ошибок

❌ Избегаем обёртывания без цели

Скрытый текст

// Плохо - создаём информационный шум
func getConfig() (*Config, error) {
    data, err := os.ReadFile("config.json")
    if err != nil {
        return nil, fmt.Errorf("failed to read config: %w", err) // лишняя обёртка
    }
    // ...
}

// Хорошо - передаём как есть
func getConfig() (*Config, error) {
    data, err := os.ReadFile("config.json")
    if err != nil {
        return nil, err // передаём оригинальную ошибку
    }
    // ...
}

Я часто видел что так делают, но не понимаю почему - мне кажется что это наоборот неудобно т.к. потом по сообщению ошибки фиг определишь что произошло, особенно если трейс не приложен.
Вот прилетит "failed to start service: EOF" и поди разберись.

Или может быть я не верно истолковал мысль?

Практика Go — Обработка ошибок (1 часть)

И fmt.Errorf("could not read config: %w", err) вместо errors.Wrap(err, "could not read config")

В лаборатории впервые воспроизвели эволюцию многоклеточного организма, создав многоклеточные дрожжи за 600 дней

Ну или развал начался из-за накопившихся проблем