Golang idiomatic error handling

I have created a "base" repository struct for standalone and embedded use (e.g with CustomerRepository) to avoid having to check errors all the time, and to create an abstraction for Gorp (the database toolkit), and to create an API slightly more to my liking.

I check for errors in this base struct and panic if one is found, as if one does exist in my opinion it then indicates a dev error and the code may as well panic, seeing as validation etc. should happen before data gets to the Repository.

I found this question https://stackoverflow.com/questions/16963298/golang-error-handling-techniques, but it doesn't cover wrapping errors up in a base struct like I have done and just panicking.

Is what I have done idiomatic Go?

package repositories
import (
"github.com/coopernurse/gorp"
)
type Repository struct {
Gorp gorp.SqlExecutor
}
func (r *Repository) GetById(i interface{}, id int) interface{} {
obj, err := r.Gorp.Get(i, id)
if err != nil {
panic(err)
}
return obj
}
func (r *Repository) Get(holder interface{}, query string, args ...interface{}) interface{} {
if err := Gorp.SelectOne(holder, query, args); err != nil {
panic(err)
}
}
func (r *Repository) Select(i interface{}, query string, args ...interface{}) {
if _, err := Gorp.Select(holder, query, args); err != nil {
panic(err)
}
}
func (r *Repository) Insert(list ...interface{}) {
if err := r.Gorp.Insert(list...); err != nil {
panic(err)
}
}
func (r *Repository) Update(list ...interface{}) int64 {
count, err := r.Gorp.Update(list...)
if err != nil {
panic(err)
}
return count
}
func (r *Repository) Delete(list ...interface{}) int64 {
count, err := r.Gorp.Delete(list...)
if err != nil {
panic(err)
}
return count
}

Don't panic, this isn't the Go way. Instead, do something like this --

func (r *Repository) GetById(i interface{}, id int) (interface{}, error) {
obj, err := r.Gorp.Get(i, id)
if err != nil {
return nil, err
}
return obj, nil
}

Then just handle the error in your caller. I see from your comments above that you are using these functions inside a Martini handler, so you would do something like this --

func MyHandler(parameters) (int, string) {
obj, err := repository.GetById(something, id)
if err == repository.ErrNotFound {
return http.StatusNotFound, fmt.Sprintf("could not find by id: %d", id)
}
if err != nil {
return http.StatusInternalError, err.Error()
}
return http.StatusOk, fmt.Printf("obj: %v", obj)
}

This is more like the Go way. Make sure that r.Gorp.Get does return specific errors that you declare inside your package.

var ErrNotFound = errors.New("not found")

Create as many as make sense to your code.

The idiomatic way would be to return the error with the associated type value, i.e.

func (list ...interface{}) (v int46, err error) {}

... and subsequently check err != nil where these functions are called.

Ultimately using panic() will result in Exception-like error handling and more boiler-plate code (if you deem the error to be recoverable).

Idiomatic error handling is verbose in Go, but less so than emulating exceptions (which is fundamentally not the "Go way").

While most code you will see in GitHub, and even in Go's own libraries is using the error as return value, this method tend to inflate and complex your code.
After several years of using Go, I found a better way to do this.
Add the following helper functions in your code:

func panicIfError(err error) {
if err != nil {
panic(err)
}
}
func getNiceError(panicError any) error {
stack := string(debug.Stack())
index := strings.LastIndex(stack, "panic")
if index != -1 {
stack = stack[index:]
index = strings.Index(stack, "\n")
if index != -1 {
stack = stack[index+1:]
}
}
return fmt.Errorf("%v\n%v", panicError, stack)
}
func recoverError(recoveredError *error) {
panicError := recover()
if panicError == nil {
recoveredError = nil
} else {
*recoveredError = getNiceError(panicError)
}
}

In your code, return errors only in central locations, such as the application HTTP server main entry for handling requests. All other functions should not return errors, but instead panic:

func f3() {
_, err := os.ReadFile("myfile.txt")
panicIfError(err)
}

In the central location, where you want to catch the errors and handle it, create a function that does return error:

func centralHandlingFunc() (recoveredError error) {
defer recoverError(&recoveredError)
callToUnsafeFunc()
return recoveredError
}

So 99% of the code uses the simple panicIfError to handle errors.
This way your code is simpler, and more readble.
Not only that, you also get the full error stack trace in case of errors, which greatly simplifier errors investigation.

I have created a post about this, you can read more details about the known error handling methods, and about this specific method: https://runkiss.blogspot.com/2022/09/go-error-handling.html