Методи поводження з помилками [закрито]

Я тільки починаю з Go. Мій код починає мати багато цього:

   if err != nil {
      //handle err
   }

або це

  if err := rows.Scan(&some_column); err != nil {
      //handle err
  }

Чи є якісні ідіоми / стратегії / найкращі практики для перевірки та обробки помилок у програмі Go?

EDIT, щоб уточнити: я не переймаюсь чи пропоную команді Go придумати щось краще. Я запитую, чи правильно я це роблю, чи пропустив якусь техніку, яку придумала громада. Дякую усім.

Ваш код ідіоматичний, і на мою думку, це найкраща доступна практика. Деякі з них не погоджуються напевно, але я стверджую, що це стиль, який бачать у всіх стандартних бібліотеках в Голангу . Іншими словами, автори Go пишуть таким чином обробку помилок.

Через шість місяців після цього запитання Роб Пайк написав повідомлення в блозі під назвою " Помилки - це цінності" .

Там він стверджує, що вам не потрібно програмувати таким чином, як представлений ОП, і згадує кілька місць у стандартній бібліотеці, де вони використовують інший малюнок.

Звичайно, загальне твердження, що включає значення помилки, - це перевірити, чи є воно нульовим, але є незліченна кількість інших речей, які можна зробити зі значенням помилки, а застосування деяких інших речей може покращити вашу програму, усуваючи велику частину котлован яка виникає, якщо кожну помилку перевіряється за допомогою оператора rote if.

...

Використовуйте мову, щоб спростити обробку помилок.

Але пам’ятайте: що б ви не робили, завжди перевіряйте свої помилки!

Це добре читати.

Я погодився би з відповіддю jnml, що вони обидва ідіоматичний код, і додати наступне:

Ваш перший приклад:

if err != nil {
      //handle err
}

є більш ідіоматичним при роботі з більш ніж однією віддаченою величиною. наприклад:

val, err := someFunc()
if err != nil {
      //handle err
}
//do stuff with val

Ваш другий приклад - це приємна стенограма, коли ви маєте справу лише зі errзначенням. Це застосовується, якщо функція повертає лише те error, або якщо ви навмисно ігноруєте повернуті значення, відмінні від error. Як приклад, це іноді використовується з функціями Readerта, Writerякі повертають intкількість записаних байтів (іноді непотрібна інформація) та an error:

if _, err := f.Read(file); err != nil {
      //handle err
}
//do stuff with f

Друга форма називається використанням оператора if ініціалізації .

Що стосується найкращих практик, наскільки я знаю (за винятком використання пакету "помилки" для створення нових помилок, коли вони вам потрібні) ви покрили майже все, що потрібно знати про помилки Go!

EDIT: Якщо ви дійсно не можете жити без винятків, можете імітувати їх defer, panic&recover .

Я створив бібліотеку для впорядкованого поводження з помилками та прокладки труб через чергу функцій Go.

Ви можете знайти його тут: https://github.com/go-on/queue

Він має компактний і багатослівний синтаксичний варіант. Ось приклад короткого синтаксису:

import "github.com/go-on/queue/q"

func SaveUser(w http.ResponseWriter, rq *http.Request) {
    u := &User{}
    err := q.Q(                      
        ioutil.ReadAll, rq.Body,  // read json (returns json and error)
    )(
        // q.V pipes the json from the previous function call
        json.Unmarshal, q.V, u,   // unmarshal json from above  (returns error)
    )(
        u.Validate,               // validate the user (returns error)
    )(
        u.Save,                   // save the user (returns error)
    )(
        ok, w,                    // send the "ok" message (returns no error)
    ).Run()

    if err != nil {
       switch err {
         case *json.SyntaxError:
           ...
       }
    }
}

Зауважте, що ефективність роботи невелика, оскільки вона використовує рефлексію.

Крім того, це не ідіоматичний код коду, тому ви хочете використовувати його у власних проектах або якщо ваша команда погодиться використовувати його.

"Стратегія" для обробки помилок у голанг та іншими мовами полягає в постійному пропонуванні помилок вверх стека викликів, поки ви не будете досить високо в стеці викликів, щоб обробляти цю помилку. Якщо ви спробували поправити цю помилку занадто рано, то, швидше за все, ви повторите код. Якщо ви впораєтесь із цим занадто пізно, то ви зламаєте щось у своєму коді. Golang робить цей процес надзвичайно простим, оскільки він дає зрозуміти, чи ви обробляєте помилку в певному місці чи поширюєте її.

Якщо ви будете ігнорувати помилку, простий _ виявить цей факт дуже чітко. Якщо ви обробляєте це, тоді точно зрозуміти, у якому випадку помилки ви обробляєте, оскільки ви будете перевіряти її в операторі if.

Як і люди, сказані вище, помилка - насправді просто нормальне значення. Це трактує це як таке.

Go Gods опублікували "проект дизайну" для обробки помилок у програмі Go 2. Він спрямований на зміну ідіоми помилок:

Огляд та дизайн

Вони хочуть відгуків користувачів!

Вікі для зворотного зв'язку

Якщо коротко, це виглядає так:

func f() error {
   handle err { fmt.Println(err); return err }
   check mayFail()
   check canFail()
}

ОНОВЛЕННЯ: Проект проекту зазнав багато критики, тому я склав вимоги до розгляду помилок Go 2 з меню можливостей для можливого рішення.

Більшість у промисловості дотримуються стандартних правил, згаданих у документації golang Поводження з помилками та Go . І це також допомагає генерації doc для проекту.

Нижче наводиться зниження рівня обробки помилок для Go, зразок для отримання параметрів HTTP URL-адреси:

(Шаблон дизайну, похідний від https://blog.golang.org/errors-are-values )

type HTTPAdapter struct {
    Error *common.AppError
}

func (adapter *HTTPAdapter) ReadUUID(r *http.Request, param string, possibleError int) uuid.UUID {
    requestUUID := uuid.Parse(mux.Vars(r)[param])
    if requestUUID == nil { 
        adapter.Error = common.NewAppError(fmt.Errorf("parameter %v is not valid", param),
            possibleError, http.StatusBadRequest)
    }
    return requestUUID
}

викликати його для кількох можливих параметрів було б нижче:

    adapter := &httphelper.HTTPAdapter{}
    viewingID := adapter.ReadUUID(r, "viewingID", common.ErrorWhenReadingViewingID)
    messageID := adapter.ReadUUID(r, "messageID", common.ErrorWhenReadingMessadeID)
    if adapter.Error != nil {
        return nil, adapter.Error
    }

Це не срібна куля, недолік - якщо у вас було кілька помилок, ви можете отримати лише останню помилку.

Але в цьому випадку це відносно повторюваний та низький ризик, тому я можу просто отримати останню можливу помилку.

ви можете очистити код обробки помилок від подібних помилок (оскільки помилки - це значення, ви повинні бути обережними тут) і написати функцію, до якої ви викликаєте помилку, передану для усунення помилки. Вам не доведеться щоразу писати "if err! = Nil {}". Знову ж таки, це призведе лише до очищення коду, але я не думаю, що це ідіоматичний спосіб робити.

Знову ж таки, тому що ви не можете означати, що слід .

goerr дозволяє обробляти помилки за допомогою функцій

package main

import "github.com/goerr/goerr"
import "fmt"

func ok(err error) {
    if err != nil {
        goerr.Return(err)
        // returns the error from do_somethingN() to main()
        // sequence() is terminated
    }
}

func sequence() error {
    ok(do_something1())
    ok(do_something2())
    ok(do_something3())

    return nil /// 1,2,3 succeeded
}
func do_something1() error { return nil }
func do_something2() error { return fmt.Errorf("2") }
func do_something3() error {
    fmt.Println("DOING 3")
    return nil
}

func main() {
    err_do_something := goerr.OR1(sequence)

    // handle errors

    fmt.Println(err_do_something)
}

Якщо ви хочете точного контролю над помилками, це може бути не рішенням, але для мене більшість випадків будь-яка помилка є пробкою шоу.

Отже, я замість цього використовую функції.

func Err(err error) {
    if err!=nil {
        fmt.Println("Oops", err)
        os.Exit(1)
    }
}

fi, err := os.Open("mmm.txt")
Err(err)