Go Error Handling Best Practices & Advanced Tips

[@GolangDojo]

Get your *FREE Golang Cheat Sheet* -
golangdojo.com/cheatsheet

[@akhiljalagam]

link doesn't work...

[@Emonadeo]

Great video, bad clickbait thumbnail

[@RichM1967]

Error handling in Go is not a mistake -- it's very good and I don't like working with languages that doesn't have something like Go's errors. What I want is a better way to handle those errors. What I would like is a function similar to 'return'.
file, err:=os.Open("my file.txt")
err.return

[@_slier]

its totally a mistake.. it outrageous.. but the golang author don't want to admit their mistake.. golang codebase littered with error handling. still not a mistake?

[@tshwarelolebeko4223]

​@@_slier what were you hoping for, try-catch?, nah that's true unnecessary with such a powerful and readable error handling system, although I love rust's error handling more, Go is also as best compared to try-catch

[@mrredogaming8885]

@@_slier if you wanted to handle every error in other languages you would have to create multiple try catch statements, but in golang you are required to handle every single error, for example making an API would provide better API errors

[@kyoukisu3628]

​@@mrredogaming8885rust be like: okey, fine

[@zanez7953]

​@@_slier Codebases handling errors is a good thing

[@nanonkay5669]

I don't understand the repetitive part that people don't like. Isn't error handling occur only as often as the number of functions that can potentially return an error? If in TS you're utilizing 20 async fxns that can error, that's 20 try-catches you need to write. Wouldn't that be called repetitive too? It really doesn't matter what language you're using, errors are going to want to be handled as often as the number of functions used that can cause them. And Go syntax to deal with them is a very short if statement

[@ViniDerp]

In TS you wouldn't necessarily have to treat errors in all of those 20 async fn calls, you can just put a try/catch block on top, which is what we often see.

[@nanonkay5669]

@@ViniDerp but if you have 20 distinct fxns that can potentially error, you need try catch all of them, if you want to get appropriate errors for each function. Putting them all in one try catch won't be helpful because if one errors, you dunno which one

[@ViniDerp]

@@nanonkay5669 I agree with you, in complex scenarios it's the best practice to do that, but let's be honest, most of the code that is in production out there doesn't have that, same thing for java.

[@KingStructre]

@@ViniDerp And yet when issue in production happens because all those try and catch, you can't tell what cause it because most of the time each developer handle it different, golang error handling enforces the best practice, handle it in small slice, and not when it part of bigger slice. I hope golang won't change error handling, because all other langauges do it wrong (talking as Java developer of 10 years which moved to golang), I am talking about projects with lot of different developers overtime, if it's a proejct when you write on your own and you know your code best, than I don't mind the try/catch or golang error handling way, but you need to remember that code is team effort (most of the time).

[@ViniDerp]

@@KingStructre Indeed, in large teams, breaking error handling into small pieces is a good way to ensure readability and maintainability. The only problem is lacking freedom to not do so, not all projects will fit this scenario, it can be quite verbose and delay development process, which is one of the reasons I define golang a niche language, not all companies will benefit from it.

[@CommonWebDev]

I love your videos. I am newbie in Golang, and i really appreciate your explanation and clear examples 👀

[@danjelhysenaj4859]

Personally, since I'm using error handling everywhere on my microservices build in Go, Our team has built a centralized library where we can use those Error handling, this way we can remove code duplications in other services.

[@RoyRope]

The Go try proposal has been declined.

[@nyahhbinghi]

show us link?

[@k98killer]

Would it not be faster to use a custom error struct that does not live on the heap? RAM access makes a much bigger performance hit than returning something that lives only in the callstack, right?

[@disculpa]

I don't know anything about go but if the error can be nil I doubt it's stored on the stack.

[@Rakstawr]

Not exactly how go works in allocating memory. Just because a var is an interface and can be nil pointer doesn't mean it is on the heap automatically.

[@casadogaspar]

Why can´t I just do:
func customError(err error, msg string) {
if err != nil {
fmt.Println(err, msg)
}
}
Or put anything you want inside the if, ErroF, log. etc?

[@antoniothomacelli]

I pay something $600 in course of Wallace (Golang Dojo) and UA-cam Videos free it is more complete than course... (SAD)

[@_slier]

2:14 look at the date of proposal.. that sum up golang core developer attitude.. no shit..

[@felipeazevedo2279]

Great content!

[@FedericoPedemonte]

caught a TooManySError at 3:05 😅

[@sidharthjawale5215]

Bulls-eye

[@staystealth]

nice clickbait

[@BenjaminLupton]

Discovered your youtube channel today and very much appreciate it! Your english is also very good, with the only shortcoming is that sometimes your pronunciation of "r" includes a "w" sound; perhaps you can hire a tutor to help with that as it can be distracting and harder to understand. Considering everything else is perfect, this would be a small fix that could go a long way. Keep up the great work, and I look forward to watching more of your videos and following your progression! Well done.

[@disculpa]

This seems idiotic to me. The code is gonna be cluttered with ugly error checks after every function call. 99% of the time you're just gonna want to return immediately on error. Newbies catching and handling errors unnecessarily is the cause of so many confusing bugs and this is just going encourage people to do that more.

[@artemsedykh]

I feel that the content in this video is outdated for several years and the author does not know about join, is, as etc.

[@nyahhbinghi]

join what?

[@artemsedykh]

@@nyahhbinghi About the errors.Join/errors.Is/errors.As.

[@ray-lee]

其實你係咪含住粒野黎講野？

[@MichaelKondrashin]

What is presented here is WRONG. Global capitalized variable "Err... = errors.New("...") should be used EVERY TIME you return custom error and not when they are common! This gives to user of your code ability to distinguish between various errors you return:
err := someFunc()
if errors.Is(err, Err...) {
Some action
} else {
...
}
Additionally, these errors should be wrapped to add context:
var ErrNegative= errors.New("negative parameter")
func foo(x int) error {
if x < 0 {
return fmt.Errorf("x = %d: %w", x, ErrNegative)
}
...
}
This gives ability to show error message "as is" or check whenever this is some particular error.
For more advanced cases, you can create hierarchy of errors, i.e.:
var (
ErrParameter = errors.New("wrong parameter")
ErrNegative = fmt.Errorf("%w: negative value")
)

[@bigtymer4862]

Try 🤮🤮🤮

[@flatearthtravolta6585]

This is terrible.

[@user-lz1gs1yl9r]

I really appreciate your work but there is no useful or new information at all in this video

[@StEvUgnIn]

lol

[@codewithtee]

I created a gofaker libary, do you mind helping to review it on your channel?

[@tmahad5447]

BEST Channel to learn Go. Dedicated channel on golang. Golang dojo

[@jed271]

Nah, anthonygg better

[@tmahad5447]

@@jed271 So why you're here!

[@mSpinks01]

@@jed271 facts, but GoLang dojo is good as well