Как продолжить выполнение программы при возникновении ошибки?

Question

[Mr.Robot]

func GetRequest(client *http.Client, method, url string) []byte {

	// request
	req, err := http.NewRequest(method, url, nil)
	if err != nil {
		log.Println("Error Occurred.", err)
	}
	response, err := client.Do(req)
	if err != nil {
		log.Println("Error sending request to API endpoint.", err)
	}
	// Close the connection to reuse it
	defer response.Body.Close()

	body, err := ioutil.ReadAll(response.Body)}
	return body
}

Данная функция работает в цикле, соотвественно, программа падает, если возникает ошибка при отправке запроса и получении ответа, можно как то сделать try, cath в go?

Comments

[Василий Банников]

Так вот этот твой if err!= nil и есть try и catch в одном лице

[Mr.Robot]

Василий Банников, в try - catch ошибка не закрывает программу.

[Василий Банников]

Mr.Robot, и что прям молча падает всё даже без паники?

[Mr.Robot]

Василий Банников, паника есть:

panic: runtime error: invalid memory address or nil pointer dereference
context deadline exceeded (Client.Timeout exceeded while awaiting headers)

Но мне не надо, что бы программа падала, если нет ответа от сайта

[Василий Банников]

Mr.Robot, но тут же прям в тексте сказано, что ты куда-то nil передал.

Думаю, в том месте, где ты response.Body.Read делаешь

Зачем пытаться дальше читать запрос, если он завершился с ошибкой?

Просто сделай сразу return в каком-нибудь из if err!=nil

[Mr.Robot]

Василий Банников, тогда следуя твоей логике, надо из функции GetRequest слать ещё error, типа если есть nil, то забей, что тоже логично.

Я вот ещё что нашел:

// panic recover(if we have not a good response)
	defer func() { //catch or finally
		if r := recover(); r != nil { //catch
			log.Println("Recover response request: ", r)
		}
	}()

[Mr.Robot]

Василий Банников, твой вариант тоже опробую, может и вправду будет проще слать ещё error.

[Максим Федоров]

Mr.Robot, нет ответа и паника — разные вещи
нет ответа = ошибка вернулась, а вы игнорируете и работаете с ответом как ни в чем не бывало
вернулась огибка, а вы логируете и дальше работаете — в чем идея с ломанным ответом работать по-вашему? :)
идея уйти от исключений и заключается — у вас есть данные в том же потоке управления ЯВНО, что "ну не пошло"
зачем второй опток организовать

там где исключения — там нет данных об этом, кроме того в языках с try/catch управление потоком работы программы — тоже плохой кейс, просто во многих языках нельзя возвращать больше 1 значения, вот и городят говно, к которому вы даже привыкли и ищите способ такого говнеца нагородить

[Максим Федоров]

Mr.Robot, отлов паники нужен, когда есть паника
у вас тут просто вернулась ошибка и есть знание об этом в err

[Mr.Robot]

Максим Федоров, тоже верно, спасибо

[Василий Банников]

Mr.Robot, отлавливать панику в этом случае - это говнокод, тк на уровне кода ты легко можешь эту панику предотвратить, если прекратишь обрабатывать запрос при ошибке

Answer 1

[off]

падает скорей все при закрытие тела запроса (которого нет при ошибке),

func GetRequest(client *http.Client, method, url string) (body []byte, err error) {
// request
req, err := http.NewRequest(method, url, nil)
if err != nil {
log.Println("Error Occurred.", err)
return
}
response, err := client.Do(req)
if err != nil {
log.Println("Error sending request to API endpoint.", err)
return
}
// Close the connection to reuse it
defer response.Body.Close()

body, err = ioutil.ReadAll(response.Body)
return
}

Comments

[Mr.Robot]

Я верно понимаю, что при возникновении ошибки,

response, err := client.Do(req)
if err != nil {
log.Println("Error sending request to API endpoint.", err)
return
}

return возвращает управление функции и тогда программа не падает?

[12rbah]

Mr.Robot, Обычно так делают, а сообщение об ошибке уже логируют в вызывающей функции.

response, err := client.Do(req)
if err != nil {
    return err
}

[Mr.Robot]

12rbah, ага, спасибо большое!

Answer 2

[12rbah]

if err != nil {
    log.Println("Error sending request to API endpoint.", err)
  }

В вашем случае не нужен try catch, у вас проблема с тем, что при возникновении ошибки вы продолжаете выполнять код, а должны вернуться из тела функции и вернуть ошибку. Но если нужны механизмы типа try catch то гуглите panic/recover