Use error decorators to simplify your error handling code

[@esra_erimez]

The importance of your content simply cannot be overstated.

[@mroobert]

When you present the problem, the function Retry is wrong. The code has " err := do() " then " if err != nil { return nil } ". It should be "if err == nil { return nil }" because you want to stop retrying if the do() method is successful. Thx for the video!

[@boldlygo]

Good catch. I noticed the same thing after it was too late.

[@ernestjohnbertillsonolaffs6461]

Technique described is very important, especially in large codebases. Example is a little contrived though.

[@boldlygo]

I actually ran into this exact scenario twice in the last week, once with each of two clients. That's what inspired me to create the video.

[@a0um]

Why Go doesn’t have proper enum types?

[@101graffhead]

This still requires the callback function to return fatal error itself, i thought it was going to be a completely external approach without touching the callback, of course using the pattern in video should be used when possible, but might not always be possible in case of using a 3rd party library function's whose fatal error equivalent is private and used internally by library itself which what i encountered at work, so what i did was actually going to library's source and copy its error string and just compared to it, its dirty but worked, since changing and forking the library was not really an option

[@boldlygo]

If you're using a library that doesn't use "intelligent" errors, string comparison may indeed be the only option. Fortunately, it's rarely the only option, as I discuss in this other video: kzbin.info/www/bejne/i5uwn3SOfruKgMk