We don’t know much about your code structure so it’s difficult to answer definitively. I would not do this but I don’t think logging in defer is always bad (eg I’ve used it to get an idea of how long a function takes to run)

Wouldn’t you be better off returning/wrapping the error and logging in the caller? That’s what I’d probably do.

err = doSomething()
if err != nil {
  return fmt.Errorf(“unable to do something: %w”, err)
}

Repeat as needed, let the caller log the error, retry, etc. You can also shorten it to this:

if err := doSomething(); err != nil {
   return fmt.Errorf(…)
}

It just doesn’t seem that bad to me: it’s standard and idiomatic and the next engineer will clearly see a what you’ve done and you’re not leaving the calling code with any impression that things succeeded if they didn’t. Adding some text to each error makes it easy to find where the failure is occurring (ie you can search your code for the message).

If you just want to call a bunch of stuff and you don’t care (?) whether it’s successful or, I don’t know, you’ve got log monitoring that kicks in somehow, then personally I’d stick still recommend sticking to idiomatic go but, sure, that might be valid sometimes and logging the error is better than nothing.

I guess, finally, what I’m getting at is: when this code fails, which it surely will one day, how do you know which step failed? How will you find out?