go-error-handlinglisted

# Go Error Handling In Go, [errors are values](https://go.dev/blog/errors-are-values) - they are created by code and consumed by code. This skill covers how to return, structure, wrap, and handle errors effectively. --- ## Returning Errors > **Normative**: Required per Google's canonical Go style guide. ### Use the `error` Type Use `error` to signal that a function can fail. By convention, `error` is the last result parameter. ```go // Good: func Good() error { /* ... */ } func GoodLookup() (*Result, error) { // ... if err != nil { return nil, err } return res, nil } ``` **Never return concrete error types from exported functions** - a concrete `nil` pointer can become a non-nil interface value: ```go // Bad: Concrete error type can cause subtle bugs func Bad() *os.PathError { /*...*/ } // Good: Always return the error interface func Good() error { /*...*/ } ``` ### Return Values on Error When a function returns an error, callers must treat all non-error return values as unspecified unless explicitly documented. Commonly, non-error return values are their zero values. **Tip**: Functions taking a `context.Context` should usually return an `error` so callers can determine if the context was cancelled. --- ## Error Strings > **Normative**: Required per Google's canonical Go style guide. Error strings should **not** be capitalized and should **not** end with punctuation: ```go // Bad: err := fmt.Errorf("Something bad happened.") // Good