As far as I'm concerned, `defer resp.Body.Close()` is perfectly cromulent and
there's no need to for error checking contortions to satisfy the lint tool. If
we're talking about a http.Request I doubt that the close can ever fail (I
haven't checked; but it doesn't seem like something that would make sense).
More generally, Close() failing on something read-only is not something I'd
worry much about. If it happens systematically there's something seriously
wrong with the system and you'll get errors from Open() or similar when you run
out of file descriptors...
//jb
> On 16 Aug 2017, at 14:18, Gert <gert.cuyk...@gmail.com> wrote:
>
> Never mind the tool is right I could print the error or something like that,
> I assumed you couldn't do anything useful with the error anyway in a defer
>
> On Wednesday, August 16, 2017 at 2:05:39 PM UTC+2, Gert wrote:
> To pass errcheck I need to do something like
>
> defer func() { _ = resp.Body.Close() }()
>
> instead of
>
> defer resp.Body.Close()
>
> Is this something the errcheck tool can figure out to mark as valid instead
> or does the errcheck tool need help from the compiler so the second case is
> also ok?
>
>
> --
> You received this message because you are subscribed to the Google Groups
> "golang-nuts" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to golang-nuts+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.
--
You received this message because you are subscribed to the Google Groups
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to golang-nuts+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
