Yes, this strategy doesn't work if you care and want to log more things other than errors. In my mind if a program doesn't work correctly it should return an error to have the opportunity to resolve the error or re-try running the code again or bubbling the error all the way up on the call stack to log it.
Still, if you want to log information other than errors it should be done separately from error handling, to rephrase that, it shouldn't be mixed with error handling.
Yes, this strategy doesn't work if you care and want to log more things other than errors. In my mind if a program doesn't work correctly it should return an error to have the opportunity to resolve the error or re-try running the code again or bubbling the error all the way up on the call stack to log it.
Still, if you want to log information other than errors it should be done separately from error handling, to rephrase that, it shouldn't be mixed with error handling.
Yes that could be better if golang support AOP, we can eliminate logging / error handling aspect away from business & system logic