Hi Jonathan. Thanks for the explanation. New to Go. This video helped. I've learnt something (dopamine=+1). In my case I needed, not so much a traditional stack trace as, an error with a flat array of errors - bunch of parallel calls, get array of errors back (or nil, or [], not sure yet :) ). So I initially started using wrap() from pkg, but then stumbled on stack-overflow question, mentioned in the video, which led me to this video :) for some reason I thought it was important to share all this... Thanks for contributing to the world's body of knowledge and pushing the expert levels up.
Thanks for taking the time to comment, Viktor. It sounds like what you may want is the new multi error support in Go 1.20. Have you seen that? tip.golang.org/doc/go1.20#errors
@@boldlygo Thanks!!! That's exactly what I wanted and tried to implement myself, but I introduced Add(e) instead of Join(...e), in my custom error. tbh Join(...e) is neater. I have to check if we're allowed to upgrade to v1.20, but this new wrap/unwrap would address my problem exactly and fully. Thanks for replying, it made my day that much better.
I find delving on past libraries not so useful, would have liked a discussion on As vs Is and how to do stack traces without the old lib. Also would have liked bigger font for code, more code time and less face time. Thanks for the video.
I think delving into the past libraries is useful to understand the history of the ecosystem. There's lots of old code out there, and knowing the history is important!
Great overview of the error fundamentals! I've recently been neck-deep in errors and wrapping for the last month or so. I made the move to completely remove pkg/errors from my codebases and construct a more simple and composable approach using curried func(error) error functions. Mostly so I can add more than just basic strings of text into errors since I make use of structured logging and properly searchable errors make a huge difference to diagnostics!
@@boldlygo nice! will keep an eye out for those! I released a package called fault recently that tackles some of these challenges, could be of interest
7:04 Is there a way to get an error that is useful not for a human, but for the calling program? For example, I could do something like this: -------------------------- nb_missing_files := 0 nb_permission_issues := 0 err := foo() if err == "failed to open file: open foo.txt: no such file or directory" { nb_missing_files++ } else if err == "failed to open file: open foo.txt: permission denied" { nb_permission_issues++ } -------------------------- But that would not be reliable, because the error messages could vary in the future.
Very clear explanation. The historical context is a great help for understanding the options and also for putting old code and advice in context.
*Every* Go programmer should be subscribed to this channel
Hi Jonathan. Thanks for the explanation. New to Go. This video helped. I've learnt something (dopamine=+1). In my case I needed, not so much a traditional stack trace as, an error with a flat array of errors - bunch of parallel calls, get array of errors back (or nil, or [], not sure yet :) ). So I initially started using wrap() from pkg, but then stumbled on stack-overflow question, mentioned in the video, which led me to this video :) for some reason I thought it was important to share all this... Thanks for contributing to the world's body of knowledge and pushing the expert levels up.
Thanks for taking the time to comment, Viktor.
It sounds like what you may want is the new multi error support in Go 1.20. Have you seen that?
tip.golang.org/doc/go1.20#errors
@@boldlygo Thanks!!! That's exactly what I wanted and tried to implement myself, but I introduced Add(e) instead of Join(...e), in my custom error. tbh Join(...e) is neater. I have to check if we're allowed to upgrade to v1.20, but this new wrap/unwrap would address my problem exactly and fully. Thanks for replying, it made my day that much better.
I find delving on past libraries not so useful, would have liked a discussion on As vs Is and how to do stack traces without the old lib. Also would have liked bigger font for code, more code time and less face time. Thanks for the video.
Great suggestion! I intend to do more on errors in the future. Stay tuned!
I think delving into the past libraries is useful to understand the history of the ecosystem. There's lots of old code out there, and knowing the history is important!
Great overview of the error fundamentals! I've recently been neck-deep in errors and wrapping for the last month or so. I made the move to completely remove pkg/errors from my codebases and construct a more simple and composable approach using curried func(error) error functions. Mostly so I can add more than just basic strings of text into errors since I make use of structured logging and properly searchable errors make a huge difference to diagnostics!
Thanks for the note! I've done similar things, and intend to discuss many of the other aspects of Go error handling in upcoming videos.
@@boldlygo nice! will keep an eye out for those! I released a package called fault recently that tackles some of these challenges, could be of interest
7:04 Is there a way to get an error that is useful not for a human, but for the calling program?
For example, I could do something like this:
--------------------------
nb_missing_files := 0
nb_permission_issues := 0
err := foo()
if err == "failed to open file: open foo.txt: no such file or directory" {
nb_missing_files++
} else if err == "failed to open file: open foo.txt: permission denied" {
nb_permission_issues++
}
--------------------------
But that would not be reliable, because the error messages could vary in the future.
That's a great question. And the answer is usually, yes. But it depends on the error. This deserves it's own video.
@@boldlygo Thank you for your reply! I'm looking forward to learning more about Go and I will definitely use your channel to do so.
Check out my new video on inspecting errors: th-cam.com/video/UjMnAXIVWJg/w-d-xo.html
@@boldlygo Wow, that's awesome, thank you very much! The video is excellent and very clear. I learned a lot.