Thanks James, are there any golang tools which could have caught this
issue. I know go vet didnt.
On Thursday, July 28, 2016 at 1:36:04 PM UTC-7, James Bardin wrote:
>
>
>
> On Thursday, July 28, 2016 at 2:34:24 PM UTC-4, krma...@gmail.com wrote:
>>
>> WHere is this documented in "On error, any
WHere is this documented in "On error, any Response can be ignored. A
non-nil Response with a non-nil error only occurs when CheckRedirect fails,
and even then the returned Response.Body is already closed"
I am interested in looking at it. I didnt find it
here https://golang.org/pkg/net/http/
http://devs.cloudimmunity.com/gotchas-and-common-mistakes-in-go-golang/index.html#close_http_resp_body
Recommends the below.
I wanted to confirm with golang people if this is indeed the correct
approach. Can the response be not nil in cases where there is an error ?
resp, err := http.Get("https
does the singleton variable for any reason need to be a pointer ?
On Thursday, June 30, 2016 at 4:07:08 PM UTC-7, Nathan Fisher wrote:
>
> I often put all of my wire-up in main which ensures that it's only one
> instance. Then I create a struct that all of the dependencies hang off of
> like log
I want a single instance of a client handle to be initialized.
Is it ok to declare the instance as
var client MetricsClient
and then initialize it using sync.Once().
Is it required for some reason that the client be a pointer or are there
are other issues with it. My requirement is to be able
