Level Up Your Web Apps With Go

Multiple Interfaces
A type isn’t limited to implementing a single interface. For example, the
Fruit
interface we saw in the first example is exactly the same as the
Stringer
interface
Level Up Your Web Apps With Go
28

---

from the
fmt
package. If you pass an instance of
Fruit
to
fmt.Println
, you’ll
see the result of the
String
method printed.
The most basic interface in the language is the empty interface
interface{}
,
which has no methods and therefore every single type implements it. A type has
no limits regarding methods that implement interface methods either; all that
matters is that the methods the interface requires exist on the type.
Error Handling
Error handling in Go is very much an in-your-face situation. A lot of languages allow
you to program without forcing you to think about error handling. You might have
the ability to rescue or catch errors, but if you don’t want to you don’t have to, and
your code will fail in interesting ways that are difficult to track.
In Go, the convention is to check for errors everywhere, and therefore be constantly
thinking about how you handle them and what they mean. While some might think
this is a terrible idea—and it certainly does lead to more code—it results in robust
code where error handling is a core part of the functionality rather than an after-
thought.
Remember earlier when we saw multiple values being returned from a function? In
most cases when you’re receiving multiple values, the last value is an error. This
means you need to assign the value to a variable (or actively choose to assign it to
the blank identifier
_
and ignore it), and check that variable. It’s very common to
see code such as this:
someValue, err := doSomething()
if err != nil {
return err // Handle the error
}
After every call to a function that returns an error, there’s a check to see whether
an error occurred and handling it if it did. More often than not, this means passing
it back up the chain for one of the calling functions to handle. While this adds lines
to your code, it also makes you think about what were to happen if this code failed
to continue on, and consider all the variations of failures that could occur. In a
world where a lot of code relies on the availability of external resources, such as
29
Go Types Explored

---

network connections and disk availability, it’s more important than ever to design
for failure, and Go surfaces this with its error handling.
So what exactly is an error? Well, it’s a great example of an interface. An error is
actually just a normal Go interface, and is any type that implements the
Error
method:
type error interface {
Error() string
}
This leads the way for us to create our own error types. We can either extend an
existing type, or create a struct with extra data. For example, if we wanted an error
type that represents an invalid HTTP status code, we could define our own integer
type:
type ErrInvalidStatusCode int
func (code ErrInvalidStatusCode) Error() string {
return fmt.Sprintf("Expected 200 ok, but got %d", code)
}
And then if we received an invalid code, we could just convert the code to the type
ErrInvalidStatusCode
:
if myStatusCode != 200 {
return ErrInvalidStatusCode(myStatusCode)
}