# Interfaces 101 : Error Handling With Go Ep. 3

DevFeed: [Interfaces 101 : Error Handling With Go Ep. 3](<https://devfeed.tech/articles/interfaces-101-error-handling-with-go-ep-3-22213.md>)

Original publisher: [Read original article](<https://www.ardanlabs.com/blog/2023/02/interfaces-101-error-handling-with-go.html>)

Published: 2023-02-13T00:00:00Z

Content type: tutorial

Language: en

Sources: [William Kennedy](<https://devfeed.tech/sources/william-kennedy.md>)

Topics: [Go Language](<https://devfeed.tech/topics/go-language.md>), [interfaces](<https://devfeed.tech/topics/interfaces.md>), [Error Handling](<https://devfeed.tech/topics/error-handling.md>)

Tags: [compiler](<https://devfeed.tech/tags/compiler.md>), [error-handling](<https://devfeed.tech/tags/error-handling.md>), [error-interface](<https://devfeed.tech/tags/error-interface.md>), [exceptions](<https://devfeed.tech/tags/exceptions.md>), [false-positives](<https://devfeed.tech/tags/false-positives.md>), [go](<https://devfeed.tech/tags/go.md>), [go-error-handling](<https://devfeed.tech/tags/go-error-handling.md>), [golang](<https://devfeed.tech/tags/golang.md>), [implement](<https://devfeed.tech/tags/implement.md>), [interfaces](<https://devfeed.tech/tags/interfaces.md>), [video](<https://devfeed.tech/tags/video.md>)

## AI overview

This video explains Go error interfaces through a custom error type and a test that unexpectedly fails when the returned error appears to be nil. It covers how Go determines whether an interface value is nil and how to avoid false positives in custom interface implementations.

## Source excerpt

Introduction In episode 2, Miki examined the impact interfaces have on the performance of a Go program. To perform this experiment, Miki invoked a type's method in two ways: with the concrete type and as an interface function to measure the difference in execution time. The conclusion of this experiment was that calling a method with the concrete type is faster than using an interface. During the experiment, Miki made use of the build flag -gcflag='-m' to display which variables were being allocated on the heap and where the compiler was automatically inlining function calls.