The secret to making Golang error handling a breeze

In this video, we delve into Golang's unique approach to error handling. We highlight how Go's error handling differs from other programming languages and showcase its effectiveness when following the right idioms. We demonstrate the simplicity of implementing the error interface and constructing errors using the errors package. We emphasize that in Go, errors are not exceptions and should be returned like any other value.
Adam provides practical examples of error handling in Go, underscoring the importance of returning both results and errors. Learn how to effectively manage errors using conditional checks and type assertions. Additionally, we explore the concept of error wrapping to provide precise insights into the origin of errors.

Third Party Review:
This video provides a great overview of idiomatic error handling in Golang. It explains how Golang handles errors differently than other languages like Java or C# that use exceptions. Instead, Golang uses explicit error returning and checking. The video covers how to create custom error types and sentinel errors in Golang. It also demonstrates error wrapping to propagate context and "stack traces" as errors bubble up through multiple levels of code. Best practices like explicitly checking for errors after function calls are shown. The presenter explains how these techniques help make error handling in Golang very visible and debuggable compared to exception handling. Overall, this is a useful tutorial for anyone wanting to understand proper error handling and propagation in Golang.

Subscribe now and Master the art of error handling in Go with us!

📒 Links 📒
Article version of this tutorial:
GO website

📒 About Earthly 📒
Earthly is a command line tool that simplifies build processes, especially for complex projects involving multiple programming languages. It helps manage communication between different languages, making builds easier to manage. If you want to streamline your build processes and work with multiple languages, Earthly can help.

[bopon]

This exactly what i needed. I came from java and javascript and not having stack tract is bugging me out in golang

[brad]

well that's a bummer. I was hoping I was missing something and my code didn't actually need to be 2/3 error handling

[ninthsun]

Thanks for awesome video. It was super helpful :D

[ixqnvxf]

thank you for the video! that was very helpful

[chickenduckhappy]

I'll show you how to sleep comfortably on a stone bed. If you're coming from other styles of appartments or hotels, you will maybe be surprised by the first impression of a stone bed. But I'll show you how to adapt and learn to enjoy sleeping in this new way that some people first feel uncomfortable with due to unfamiliarity with how the extremely cold and hard surface feels.

[wsollers]

I have the urge to run a sed before compiling to add line numbers to go source code. There has to be a better way to find the source of a fault than using programmer supplied strings

[duongphuhiep]

what bothering me is not the verbosity of "if err != nil", rather the fact that: 

(1) "Hidding error and continue running is the nature of Go codes" at least it is the default behavior when you "forgot" to handle error... On the other side, the "Exception paradigm" of Java, C# makes your codes crash if you "forgot" to handle the "exception" other function is throwing. 

(2) The "if err != nil" of Go is "contaminating" the same way as the "async await". It means that if you "forgot" only one line of "if err != nil" in the chain, then the worst case is that others "if err != nil" (in the chain) might be wasted. The longer the codes continue to run with the hidden error until the day it finally crashed, the harder to track down the root cause. 

Fortunately this worst case is not that common IME. Moreover, the golangci-lint gives you a big "errchecked" warning. Personally, I don't let any of these warnings appeared in my codes. Evens in case I wanted to skip / ignore an error, I'd still "if err != nil" to log the error (in debug level) along with a justification message explaining why I ignored the error (and so continued the happy path)

I wish that Go team would inspire the same approach as Rust for error handling. Rust errors are Value the same way as Go, but the Result<T, E> of Rust beautifuly "forced" developers to handle error: In order to Get the result T you have to handle the "E" one way or other: in a "match" statement or by a simple unwrap() function to get the T which will panic the E... 

Unfortunately, It might be too late now for Go to take the same approach as Rust because Go has to keep backward compatibility with the current "if err != nil" way of errors handling.

[danielniels]

When to create a custom error by implementing the error interface, or when to use the errors.New() ?

[rubenchiquin]

People often criticize this way of handling errors, but it is probably due to a majority of people coming from a language where errors are ghosts, and you don't even know they can happen. That's why it might feel easier to deal with errors, because you are not forced to handle them.

Sure, maybe some errors almost never happen and it might not even be worth handling them, but in my opinion If a language forces you to do very robust programs, where you handle all scenarios, that's a good thing, not a bad one.

If you wanna write lazy code that breaks, but write it in 1 minute, then go with Python, because in Go it will be way harder to do bad code.

[Drygear]

I might be missing some obvious point but it seems Go error handling is sooo many lines of code just to handle one error.

[salmanansari]

Sometimes I hate go error handling so much