Go Error Handling: Values Over Exceptions

Go treats errors as values rather than exceptions, requiring explicit handling by checking returned error values. Functions that may fail return an error as their last value, following the convention `(result, error)`. The caller must check this error, as seen in the `ReadFile()` example which returns `nil` and an error when the path is empty. Go's built-in `error` type is an interface requiring only an `Error() string` method, allowing custom error implementations. While Go provides `panic` and `recover` mechanisms similar to exceptions in other languages, they're intended only for unrecoverable errors like invalid regular expression compilation, where `regexp.MustCompile()` deliberately panics. For network operations, `net.OpError` enables checking temporary failures for retry logic, while I/O functions like `io.Reader.Read()` return bytes processed before failure for partial recovery. Common mistakes include ignoring errors by assigning them to `_` or failing to wrap errors with context using `fmt.Errorf()` and `%w`. Custom error types like `os.PathError` can carry additional diagnostic information. Logging should avoid `log.Fatal()` outside `main()` since it bypasses deferred cleanup, and recovery strategies should weigh the cost of restarting versus continuing operations, as seen in HTTP server handlers.