The secret to making Golang error handling a breeze

Earthly ➤ earthly.dev
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!
➡️ Earthly: earthly.dev/
📒 Links 📒
Article version of this tutorial:
earthly.dev/blog/golang-errors/
GO website
go.dev/
📒 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.

[@ninthsun]

Thanks for awesome video. It was super helpful :D

[@EarthlyTech]

Glad it was helpful!

[@user-ix5qn5vx5f]

thank you for the video! that was very helpful

[@EarthlyTech]

You're welcome!

[@brad8549]

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

[@GOTHICforLIFE1]

it doesn't - you can choose to let your functions simply not check if it will return an error by not check for nil or specific errors vars. it's not like other languages doesn't have shit ton of error handling if it's properly robust. It's just that Go kinda requires you to ignore errors instead with either underscore or simply not storing the function return values at all in case where a function only returns an error.

[@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 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.

[@rubenchiquin3768]

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.

[@wsollers1]

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

[@EarthlyTech]

golang preprocessor 😬

[@danielniels22]

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

[@sczoot6285]

Without exploring the different approaches, I would say implement the interface when you want to add additional state/functionality to what the error struct would provide

[@Drygear1]

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

[@Nuraddinhassan]

if you never touched Golang of course it will seem horrible, for me I just create standard approach/plan to handle it and now just follow that approach. it will be really messy if you just try to figure out how to handle it for every time you face error in code.

[@salman0ansari]

Sometimes I hate go error handling so much

[@EarthlyTech]

I like how Rust uses the Result type. I'd like that in go.

[@benjiro8793]

@@EarthlyTech Good luck getting that ever. The "community" consensus seems to be "everything is fine, and all the people complaining need to be beaten until they like the current way of doing things". Que Generics, que modules, que ... same community backlash and now, ... its perfectly accepted. It takes too long for quality of life features to get added, and we then get inter solutions that do not solve the actual issues (but create excuses to not fix the issue).

[@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.

[@EarthlyTech]

😂