News for hackers. Stuff that matters.
Re:Gopher Wrangling. Effective error handling in Go by janosdebugs on Tuesday June 20, 2023 @07:10AM (#36402353)
> You have to go out of your way to actually use a special character to do it.

Only if the function returns more than the error. You can happily do this without errors:

   fh = os.Create("/some/file")
   defer fh.Close()
Needless to say, this is a terrible idea if the underlying filesystem can give you an error at close time, e.g. on NFS. The correct way to write the above code would be:

   fh = os.Create("/some/file")
   defer func() {
      if err := fh.Close(); err != nil {
          // Do something with the error
      }
   }()
Yet, I see a lot of the former and very few instances of the latter.
Re:Gopher Wrangling. Effective error handling in Go by aatd86 on Tuesday June 20, 2023 @08:28AM (#36403065)
Oh you're right. I had forgotten about that.

I think it's mostly an API legacy mistake. Close should probably return (bool, error).

Probably a remnant of coding in C wrt sentinel values.

Re:Gopher Wrangling. Effective error handling in Go by janosdebugs on Tuesday June 20, 2023 @08:56AM (#36403319)
You could still ignore both returned values. Go shouldn't allow ignoring returns without explicit dogsleds (underscore) at all if it were to stay "in character".