{"id":177,"date":"2026-07-07T20:34:49","date_gmt":"2026-07-07T20:34:49","guid":{"rendered":"https:\/\/kindsonthegenius.com\/go\/2026\/07\/07\/10-go-interfaces-and-errors\/"},"modified":"2026-07-07T20:38:30","modified_gmt":"2026-07-07T20:38:30","slug":"10-go-interfaces-and-errors","status":"publish","type":"post","link":"https:\/\/kindsonthegenius.com\/go\/2026\/07\/07\/10-go-interfaces-and-errors\/","title":{"rendered":"Go Interfaces and Errors \u2013 Polymorphism and Idiomatic Error Handling"},"content":{"rendered":"

<\/p>\n

\n

Updated July 2, 2026.<\/strong> Refreshed for Go 1.22+ and current SEO best practices.<\/p>\n<\/div>\n

In this lesson we cover Go interfaces and errors<\/strong> \u2014 two features that shape how production Go code is structured. Interfaces provide implicit polymorphism: a type satisfies an interface by implementing its methods, with no implements<\/code> keyword. The error<\/code> type is a built-in interface that every Go developer uses daily. This lesson focuses especially on Go error handling<\/strong> \u2014 the idiomatic patterns that replace exceptions in other languages.<\/p>\n

Prerequisites:<\/strong> Lessons 1\u20139 completed, Go 1.22 or newer installed. Estimated time:<\/strong> 50\u201360 minutes.<\/p>\n

1. The error Type and Basic Handling<\/h4>\n

In Go, functions signal failure by returning an error<\/code> as the last return value. The error<\/code> interface is minimal \u2014 any type with an Error() string<\/code> method satisfies it:<\/p>\n

type error interface {\n\tError() string\n}\n<\/code><\/pre>\n
The standard pattern is to check the error immediately after the call:<\/p>\n
package main\n\nimport (\n\t\"fmt\"\n\t\"os\"\n)\n\nfunc main() {\n\tdata, err := os.ReadFile(\"config.json\")\n\tif err != nil {\n\t\tfmt.Println(\"failed to read config:\", err)\n\t\treturn\n\t}\n\tfmt.Printf(\"read %d bytes\\n\", len(data))\n}\n<\/code><\/pre>\n
There are no try\/catch blocks. Errors are explicit values<\/strong> that flow through your program. This verbosity is intentional \u2014 it forces you to decide what to do at each failure point: retry, log, return upstream, or abort.<\/p>\n
2. Creating and Returning Errors<\/h4>\n
Use errors.New<\/code> for simple messages and fmt.Errorf<\/code> for formatted messages. Return nil<\/code> when there is no error:<\/p>\n
package main\n\nimport (\n\t\"errors\"\n\t\"fmt\"\n)\n\nvar ErrNotFound = errors.New(\"book not found\")\n\nfunc findBook(id int) (string, error) {\n\tbooks := map[int]string{1: \"The Go Programming Language\", 2: \"Concurrency in Go\"}\n\ttitle, ok := books[id]\n\tif !ok {\n\t\treturn \"\", ErrNotFound\n\t}\n\treturn title, nil\n}\n\nfunc divide(a, b float64) (float64, error) {\n\tif b == 0 {\n\t\treturn 0, fmt.Errorf(\"divide: cannot divide %g by zero\", a)\n\t}\n\treturn a \/ b, nil\n}\n\nfunc main() {\n\ttitle, err := findBook(99)\n\tif err != nil {\n\t\tfmt.Println(err) \/\/ book not found\n\t\treturn\n\t}\n\tfmt.Println(title)\n}\n<\/code><\/pre>\n
Export sentinel errors like ErrNotFound<\/code> (uppercase) so callers can compare them with errors.Is<\/code>. Keep error messages lowercase and without trailing punctuation \u2014 they are often wrapped and concatenated.<\/p>\n
3. Wrapping Errors with %w<\/h4>\n
When a lower-level error bubbles up through your code, wrap<\/strong> it with context using fmt.Errorf<\/code> and the %w<\/code> verb. Wrapping preserves the original error for inspection while adding a human-readable layer:<\/p>\n
package main\n\nimport (\n\t\"errors\"\n\t\"fmt\"\n\t\"os\"\n)\n\nfunc loadConfig(path string) error {\n\t_, err := os.ReadFile(path)\n\tif err != nil {\n\t\treturn fmt.Errorf(\"loadConfig(%q): %w\", path, err)\n\t}\n\treturn nil\n}\n\nfunc main() {\n\terr := loadConfig(\"\/etc\/app\/config.json\")\n\tif err != nil {\n\t\tfmt.Println(err)\n\t\t\/\/ loadConfig(\"\/etc\/app\/config.json\"): open \/etc\/app\/config.json: no such file or directory\n\n\t\tif errors.Is(err, os.ErrNotExist) {\n\t\t\tfmt.Println(\"\u2192 config file is missing \u2014 create one or check the path\")\n\t\t}\n\t}\n}\n<\/code><\/pre>\n
errors.Is(err, target)<\/code> walks the unwrap chain to find a matching error. errors.As(err, &target)<\/code> extracts a specific error type from the chain. These functions replaced fragile string matching and are essential in modern Go error handling.<\/p>\n
4. Interfaces \u2014 Implicit Satisfaction<\/h4>\n
An interface<\/strong> defines a set of method signatures. A type satisfies an interface by implementing those methods \u2014 no declaration required. The empty interface interface{}<\/code> (or any<\/code> since Go 1.18) is satisfied by every type.<\/p>\n
package main\n\nimport \"fmt\"\n\ntype Speaker interface {\n\tSpeak() string\n}\n\ntype Dog struct{ Name string }\ntype Cat struct{ Name string }\n\nfunc (d Dog) Speak() string  { return d.Name + \" says Woof!\" }\nfunc (c Cat) Speak() string  { return c.Name + \" says Meow!\" }\n\nfunc announce(s Speaker) {\n\tfmt.Println(s.Speak())\n}\n\nfunc main() {\n\tannounce(Dog{Name: \"Rex\"})\n\tannounce(Cat{Name: \"Luna\"})\n}\n<\/code><\/pre>\n
Interfaces enable polymorphism and dependency injection. The announce<\/code> function accepts any Speaker<\/code> \u2014 it does not care whether the concrete type is a Dog<\/code> or Cat<\/code>. Small interfaces (one or two methods) are preferred \u2014 “the bigger the interface, the weaker the abstraction.”<\/p>\n
5. Standard Library Interfaces \u2014 io.Reader and io.Writer<\/h4>\n
The most important interfaces in Go live in the io<\/code> package. io.Reader<\/code> and io.Writer<\/code> abstract reading and writing from files, network connections, buffers, and more:<\/p>\n
package main\n\nimport (\n\t\"fmt\"\n\t\"io\"\n\t\"strings\"\n)\n\nfunc copyAndUppercase(w io.Writer, r io.Reader) error {\n\tdata, err := io.ReadAll(r)\n\tif err != nil {\n\t\treturn fmt.Errorf(\"copyAndUppercase: read: %w\", err)\n\t}\n\t_, err = w.Write([]byte(strings.ToUpper(string(data))))\n\tif err != nil {\n\t\treturn fmt.Errorf(\"copyAndUppercase: write: %w\", err)\n\t}\n\treturn nil\n}\n\nfunc main() {\n\tvar buf strings.Builder\n\tinput := strings.NewReader(\"hello, interfaces\")\n\tif err := copyAndUppercase(&buf, input); err != nil {\n\t\tfmt.Println(\"error:\", err)\n\t\treturn\n\t}\n\tfmt.Println(buf.String()) \/\/ HELLO, INTERFACES\n}\n<\/code><\/pre>\n
Design your own packages around small interfaces. Accept io.Reader<\/code> instead of a file path when possible \u2014 callers can pass strings, HTTP bodies, or compressed streams without changing your function.<\/p>\n
6. Custom Error Types<\/h4>\n
For errors that carry structured data \u2014 HTTP status codes, field names, retry hints \u2014 define a custom type with an Error()<\/code> method:<\/p>\n
package main\n\nimport (\n\t\"errors\"\n\t\"fmt\"\n\t\"strings\"\n)\n\ntype ValidationError struct {\n\tField   string\n\tMessage string\n}\n\nfunc (e *ValidationError) Error() string {\n\treturn fmt.Sprintf(\"validation failed on %q: %s\", e.Field, e.Message)\n}\n\nfunc validateEmail(email string) error {\n\tif email == \"\" {\n\t\treturn &ValidationError{Field: \"email\", Message: \"required\"}\n\t}\n\tif !strings.Contains(email, \"@\") {\n\t\treturn &ValidationError{Field: \"email\", Message: \"must contain @\"}\n\t}\n\treturn nil\n}\n\nfunc main() {\n\terr := validateEmail(\"\")\n\tvar ve *ValidationError\n\tif errors.As(err, &ve) {\n\t\tfmt.Printf(\"field=%s message=%s\\n\", ve.Field, ve.Message)\n\t}\n}\n<\/code><\/pre>\n
Use errors.As<\/code> to extract *ValidationError<\/code> from a wrapped error chain. This pattern powers HTTP handlers that map validation failures to 400 responses and database errors to 500 responses \u2014 exactly what you will build in the Lesson 12 REST API capstone.<\/p>\n
7. panic, recover, and When Not to Use Them<\/h4>\n
panic<\/code> stops normal execution and unwinds the stack. Use it for truly unrecoverable programmer errors \u2014 not for expected failures like a missing file or invalid user input. Those belong in error<\/code> returns.<\/p>\n
package main\n\nimport \"fmt\"\n\nfunc safeDivide(a, b int) (result int, err error) {\n\tdefer func() {\n\t\tif r := recover(); r != nil {\n\t\t\terr = fmt.Errorf(\"recovered from panic: %v\", r)\n\t\t}\n\t}()\n\treturn a \/ b, nil \/\/ panics if b == 0\n}\n\nfunc main() {\n\tresult, err := safeDivide(10, 0)\n\tif err != nil {\n\t\tfmt.Println(err) \/\/ recovered from panic: runtime error: integer divide by zero\n\t\treturn\n\t}\n\tfmt.Println(result)\n}\n<\/code><\/pre>\n
recover()<\/code> only works inside deferred functions. HTTP servers use it in middleware to catch panics and return 500 instead of crashing the process. For application logic, prefer explicit error returns \u2014 they are easier to test and reason about.<\/p>\n
8. Next Steps<\/h4>\n
You now understand Go interfaces and errors<\/strong> \u2014 the error<\/code> interface, wrapping with %w<\/code>, errors.Is<\/code> and errors.As<\/code>, implicit interface satisfaction, and when to use panic. In the next lesson we explore goroutines and channels<\/strong> \u2014 Go’s built-in concurrency model that makes it a top choice for networked services.<\/p>\n
Continue the series: Lesson 9 \u2013 Pointers<\/a> \u00b7 Lesson 11 \u2013 Goroutines and Channels<\/a><\/p>\n
Frequently Asked Questions<\/h4>\n
Why does Go not have exceptions?<\/strong>
\nGo treats errors as values returned from functions. This makes failure paths explicit and visible at every call site, which improves reliability in large codebases and concurrent programs.<\/p>\n
What is the difference between errors.Is and errors.As?<\/strong>
\nerrors.Is<\/code> checks whether any error in the unwrap chain equals a target sentinel error. errors.As<\/code> extracts a specific error type<\/em> from the chain into a variable you provide.<\/p>\n
How do interfaces work in Go?<\/strong>
\nA type satisfies an interface by implementing its methods \u2014 no implements<\/code> keyword needed. Interfaces are satisfied implicitly, enabling flexible, decoupled designs.<\/p>\n
<\/p>\n