DP
нет, на ошибке мы можем выходить из функции, но наличие ошибки не гарантирует пустой resp.Body
точно?
Size: a a a
2019 December 29
RD
Точно
DP
а в каком случает там непустой боди?
RD
ммм. со стандартным клиентом - ни в каком, пожалуй.
DP
ммм. со стандартным клиентом - ни в каком, пожалуй.
вот и я что-то такое помню… но пользуюсь редко, мог и забыть
ВС
resp, err := http. ...
if resp != nil {
defer resp.Body.Close()
}
if err != nil {
...
ВС
Я честно говоря не совсем понимаю что именно мне панику выдает
DP
коллега, вы получаете на post ошибку, но продолжаете обработку. конечно, как только вы пытаетесь потом ответом воспользоваться - у вас паника
ВС
Спасибо
RC
не надо так нервничать, коллега
воркер пулы не нужны
обычно ограничивать потребление ресурсов следует на шаг раньше, чем непосредственно обработка.
видимо - это и есть та дичайшая чушь 🙂
воркер пулы не нужны
обычно ограничивать потребление ресурсов следует на шаг раньше, чем непосредственно обработка.
видимо - это и есть та дичайшая чушь 🙂
да, такие комментарии поверхностны. потому что нет понимания инструмента "пул воркеров". вместо того, чтобы запустить n горутин советовать ограничивать потоки данных и управления "где то еще" - это что то вроде совета программировать не на го, а на баше.
DP
да, такие комментарии поверхностны. потому что нет понимания инструмента "пул воркеров". вместо того, чтобы запустить n горутин советовать ограничивать потоки данных и управления "где то еще" - это что то вроде совета программировать не на го, а на баше.
ну или вы не дали себя понять, о чем ваш оппонент.
правда в том, что на этапе обработки ограничивать потребление обычно поздно - ни ошибку вернуть, ни потоком порулить.
правда в том, что на этапе обработки ограничивать потребление обычно поздно - ни ошибку вернуть, ни потоком порулить.
RD
вот и я что-то такое помню… но пользуюсь редко, мог и забыть
Долго пытался сообразить, где первоначально я увидел рекомендацию явно проверять response на nil, причём до проверки ошибки. Нашёл:
http://devs.cloudimmunity.com/gotchas-and-common-mistakes-in-go-golang/#anameclose_http_resp_bodyaclosinghttpresponsebody
http://devs.cloudimmunity.com/gotchas-and-common-mistakes-in-go-golang/#anameclose_http_resp_bodyaclosinghttpresponsebody
DP
Долго пытался сообразить, где первоначально я увидел рекомендацию явно проверять response на nil, причём до проверки ошибки. Нашёл:
http://devs.cloudimmunity.com/gotchas-and-common-mistakes-in-go-golang/#anameclose_http_resp_bodyaclosinghttpresponsebody
http://devs.cloudimmunity.com/gotchas-and-common-mistakes-in-go-golang/#anameclose_http_resp_bodyaclosinghttpresponsebody
это авторитетный источник, да. спасибо!
RC
ну или вы не дали себя понять, о чем ваш оппонент.
правда в том, что на этапе обработки ограничивать потребление обычно поздно - ни ошибку вернуть, ни потоком порулить.
правда в том, что на этапе обработки ограничивать потребление обычно поздно - ни ошибку вернуть, ни потоком порулить.
если все такие конвееры находятся в рамках одного сервиса, то не поздно. так же не поздно, если инфраструктура не позволяет внешнее управление мощностью очередей.
DP
если все такие конвееры находятся в рамках одного сервиса, то не поздно. так же не поздно, если инфраструктура не позволяет внешнее управление мощностью очередей.
мы зашли на второй круг. давайте сворачиваться, а?
RC
а с чем сворачиваться то? какое резюме? пул воркеров редкий паттерн, нужен для искусственного ограничения ресурсов на обработку потока данных, ниже, чем доступно процессу.
DP
и от меня добавление: если вам показалось, что в go вам нужен пул - скорее всего, вы ошибаетесь, поглядите на архитектуру еще раз
RC
а? :) Мы же тратим время на создание гоурутины, выделяем память, инициализируем внутри что-то (ну например библиотека по парсингу DOM)
тратим только один спан 8кб на одну горутину, это в целом действительно довольно быстро. но это при условии, что у нас оперативная память резиновая.
RC
и от меня добавление: если вам показалось, что в go вам нужен пул - скорее всего, вы ошибаетесь, поглядите на архитектуру еще раз
ок, согласен.
IK
Уважаемые, а как работать с документацией, если в проекте несколько сервисов на разных языках, например?