Golang error handling practical tips for personal projects

• Motivation
• Tired of handling errors
• In main function
• In a Test* function
• In a function without calling another function that returns an error
• In a function that calls another function that returns an error

I do not want to waste my time again on hesitating to choose which pattern to handle an error in Golang, neither refactoring a bunch of code to fit a new error handling pattern. So here are some tips to help to choose a fine enough error handling pattern in different situations. They are from my own Golang personal project experience, which is mainly for academic use but with an engneering expectation.

• Q: Do you want others to reuse this code?
  • Y -> Always return an error
  • N -> Always panic

• Q: Does the main has several pretty individual sections?
  • Y -> Always panic still, but panic in the individual section other than main after returning from the section
  • N -> Always panic

Always t.Fatal, and even use t.Run for sub-testcases so that t can be passed

• Q: Does the function has failure situations, e.g., map access returns ok == false?
  • Y -> Return an error, and add a global exported Err-prefixed var with a custom string to return in the situation
  • N -> So you do not have an error to handle

• Q: Do all errors possibly from these called functions can be considered and handled in the function?
  • Y -> So you do not have an error to handle
  • N -> Q: Are these called functions in goroutine?
    • Y -> Use an error channel to collect errors, and return the first error, or wrap them into a single error and return it
    • N -> Return an error