hi @feketegy
, I believe that would be awesome if all the functions you mentioned are return error, but it'll be hard if the functions return something else other than error. But it is possible to decorate all the function to collect the error, I've tried another method to trace the error stack using panic but not recommended
But I also believe decorating handler with middleware is not a horrible pattern since google put context as the first argument in their functions
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.
hi @feketegy , I believe that would be awesome if all the functions you mentioned are return error, but it'll be hard if the functions return something else other than error. But it is possible to decorate all the function to collect the error, I've tried another method to trace the error stack using panic but not recommended
But I also believe decorating handler with middleware is not a horrible pattern since google put context as the first argument in their functions
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