Use error decorators to simplify your error handling code

Imagine you've written a Retry function that accepts a callback function as an argument, and executes it in a loop until success. Now further imagine that some errors should not be retried. Learn how to use a simple custom error type implimentation as a decorator type, to simplify this type of logic.

Other videos of mine on the topic of errors and error wrapping:

[esra_erimez]

The importance of your content simply cannot be overstated.

[ernestjohnbertillsonolaffs]

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

[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!

[aum]

Why Go doesn’t have proper enum types?

[graffhead]

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