Как вы обрабатываете ошибки в Web приложении на Go?

Question

[Dmitry Shnyrev]

Привет!

Поделитесь рецептом, как правильно собирать и обрабатывать ошибки в web приложении на Go.
Для себя пока нашел такой вариант, не уверен что это хороший пример:
использую библиотеку https://github.com/golang/glog
просто в любом месте приложения ставлю

if err != nil {
glog.Fatalln(err)
}

и в браузере получаю 500 Server internal error, а в логах:
F1106 07:15:27.296630 02050 services.go:42] My Error
где видно когда и где произошла ошибка.
(! плохой способ я выбрал - upd внизу)

Еще нашел информацию вот здесь https://sourcegraph.com/blog/google-io-2014-buildi...

Handler functions: We define our handlers with an error return value, and we use a simple wrapper function to make them implement http.Handler. This means we can centralize error handling instead of having to format error messages and pass them to the http.Error for each possible error. Our handler functions look like:
func serveXYZ(w http.ResponseWriter, r *http.Request) error { ... }

Попробовал. Но собирать ошибку и поднимать ее по иерархии до самого верхнего уровня как-то не очень красивы в итоге получается.

Какие есть рецепты у вас? Что можете сказать по этому поводу?

upd: Разработку я веду при помощи gin, который отвечает за перезагрузку сервера. Поэтому получилось что после glog.Fatal сервер вырубался по os.Exit(255), а gin врубал его обратно. Мне казалось что просто завершается текущий запрос. Попробовал запустить сервер напрямую и действительно на строчке с ошибкой сервер остановился. Не гуд :(.
pps: сделал для себя открытие проект с несколькими файлами в одном package нельзя просто так оказывается запустить с помощью go run server.go, надо делать go run *.go ! О как :). До этого момента подгрузкой файлов из одного package занимался gin :)

Answer 1

[SilentFl]

если вы делаете все руками через net/http, то можно ловить panic (ну или error), и логировать с нужной инфой:

package main

import (
	"fmt"
	"log"
	"net/http"
)

func handle(w http.ResponseWriter, r *http.Request) {
	defer func() {
		if s := recover(); s != nil {
			log.Printf("Recover in %s\n", s)
			log.Printf("Request: %s\n", fmt.Sprintf("%+v", r))
			http.Error(w, "Sorry, something wrong. Try later", 500)
		}
	}()

	// тут делаем какую-то вещь, которая крашит горутину (допустим, валится вызов библиотечной функции)
	// для примера сделаем так:
	someCondition := true
	if someCondition {
		panic("Root")
	}

	w.Write([]byte("Hello"))
}

func main() {
	http.Handle("/", http.HandlerFunc(handle))
	http.ListenAndServe(":8080", nil)
}

ну а если будете использовать какой-нибудь фреймворк, то смотрите в его документацию; допустим в beego есть свой логгер, с уровнями и всем прочим

Comments

[Dmitry Shnyrev]

Спасибо за ответ. Для себя заново открыл recovery :)
Пример и идею обработки ошибок вашу понял, погуглил чтобы развить эту тему.
Вот на такую интересное обсуждение натолкнулся
www.reddit.com/r/golang/comments/2a1sie/when_to_ca...
Большинство советует использовать панику в крайних случаях, request handlers к которым не относится.

Для себя выработал решение:
в месте ошибки записывать данные в лог и поднимать ошибку выше через return, а в контроллере отправлять http.Error(w, http.StatusText(500), 500) и прерывать выполнение.
Вроде работает :) ошибки пишутся в лог (с нужными данными - где и когда), а пользователь получает свою 500.

[SilentFl]

panic я привел здесь просто для примера, когда от ошибки отмахнуться просто так нельзя. Если ошибка recoverable - то либо ставим ее обработку через if err != nil { /*обрабатываем ситуацию*/ }, либо if err != nil { return nil, err /*возвращаем пустой результат, и говорим что на этих входных данных возникла ошибка*/ }, в зависимости от ситуации

Answer 2

[uvelichitel]

"Error values in Go aren’t special, they are just values like any other, and so you have the entire language at your disposal." Rob Pike at Gophercon 2014
Error в Go - это еще не повод для panic. Вы можете сделать запрос к DB и получить error потому, что DB перегружена или сбой на линии или запрос некорректен - это вовсе не основание вызывать glog.Fatalln(err), который сам вызывает os.Exit(255). Просто обрабатывайте error, как значение обычного типа на месте или передавайте выше по стеку вызывов и двигайтесь дальше. Всякий error имеет метод error.Error() возвращающий string для удобства пользования, каковой string можно например отрендерить в HTML пользователю или напечатать в терминал ну или передать в логгер для отладки. Чего уж так сразу panic, fatal?)))
Если я правильно понял вопрос.

Comments

[Dmitry Shnyrev]

Вы все правильно поняли! И подтвердили информацию которую я почерпнул в ходе изучения этого вопроса. Собственно так сейчас и делаю. Никаких panic и glog.fatal :)
Подскажите такой вопрос. Это уже для интереса. Как бы в месте появления ошибки я руками записываю текстовое представление в glog.Error, который мне сохраняет информацию вместе с данными где я вызвал этот самый glog.Error в таком виде [E1107 18:20:58.734819 06405 server.go:39]. Но это данные не о самой ошибке, а именно о самом выводе, которые косвенно указывают на то место где произршла ошибка. А можно как-то эту информацию достать из самого объекта error, кроме его текстового представления?

[uvelichitel]

В общем случае error.Error() string - это все, что обязательно спецификацией языка. Большинство логгеров извлекают это сами, достаточно им передать error. Есть еще сообщения runtime и OS в системной консоли и coredump, но это в случае крушений.

[Dmitry Shnyrev]

"Большинство логгеров извлекают это сами, достаточно им передать error." какие логгеры можете посоветовать. Использую glog но что-то у него документация слишком скудная.

[uvelichitel]

Тут из меня плохой советчик, я к стыду своему пользуюсь fmt.Println(error.Error()). Из общих соображений log в stdlib потому, что stdlib и glog потому, что его пользуют в google

[Dmitry Shnyrev]

Ну в принципе, если логически подумать, какая разница из каких недр мы получили ошибку, ведь она по стеку может подниматься долго. А в том месте где мы ее получили просто ставим вывод этой ошибки (ее текстовое представление) и тот же glog любезно предоставляет информацию где и когда он вывел информацию в лог. Мы уже может по этим данным найти место где был вывод в лог ошибки и разобраться в чем дело. :)

[Dmitry Shnyrev]

Michail Wowtschuk: Уже врядли подскажу - забросил go примерно в то же время как писал этот вопрос. Попробовал - не взлетело.

Answer 3

[Dmitry Shnyrev]

Нашел такой интересный сервис
https://deferpanic.com/

Comments

[SilentFl]

и получится что проект будет зависеть от стороннего сервиса. Конечно, понимаю, что красивые графики и все такое, но, имхо, лучше потерять день и прикрутить свою статистику