Go Error Handling Best Practices & Advanced Tips

Подписаться 40 тыс.

Просмотров 36 тыс.

50% 1

Depending on who you talk to, Go error handling is either the worst mistake the language designers ever made or a feature of the language that saves you from error handling complications. With that said, if you want to write proper Go code, it's important to understand how's and why's. Watch this video if you want to learn the best practices and advanced tips for how to handle errors in Go. Enjoy.
--
Golang Dojo is all about becoming Golang Ninjas together. You can expect all kinds of Golang tutorials, news, tips & tricks, and my daily struggles as a Golang developer. Make sure to subscribe if you look forward to such content!
Get Your Golang Cheat Sheet! - golangdojo.com/cheatsheet
Git repos & notes - golangdojo.com/resources
Golang Basics - • Golang Basics - Instal...
Golang Informative - • How much do Golang dev...
--
Timestamps
0:00 Intro
0:46 Tip 1
2:27 Tip 2
3:03 Tip 3
3:54 Tip 4
4:42 Tip 5
5:16 Tip 6
5:51 Honorable mentions
--
#golang #goprogramming #golangdojo

Наука

Опубликовано:

25 июл 2024

Ссылка:

Скачать:

Готовим ссылку...

Добавить в:

Мой плейлист

Посмотреть позже

Комментарии : 49

@GolangDojo Год назад

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

@akhiljalagam 5 месяцев назад

link doesn't work...

@Emonadeo Год назад

Great video, bad clickbait thumbnail

@CommonWebDev Год назад

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

@felipeazevedo2279 Год назад

Great content!

@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 10 месяцев назад

@@mrredogaming8885rust be like: okey, fine

@zanez7953 10 месяцев назад

@@_slier Codebases handling errors is a good thing

@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 8 месяцев назад

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

@Rakstawr 4 месяца назад

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 2 месяца назад

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?

@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 10 месяцев назад

@@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 10 месяцев назад

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

@danjelhysenaj4859 3 месяца назад

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 9 месяцев назад

The Go try proposal has been declined.

@nyahhbinghi 7 месяцев назад

show us link?

@FedericoPedemonte Год назад

caught a TooManySError at 3:05 😅

@sidharthjawale5215 Год назад

Bulls-eye

@codewithtee 9 месяцев назад

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

@ray-lee Год назад

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

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

@_slier Год назад

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

@antoniothomacelli Год назад

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

@artemsedykh 8 месяцев назад

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 7 месяцев назад

join what?

@artemsedykh 7 месяцев назад

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

@StEvUgnIn Год назад

lol

@disculpa 8 месяцев назад

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.

@staystealth 8 месяцев назад

nice clickbait

@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

@MichaelKondrashin 7 месяцев назад

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") )