rething error handling
Closed this issue · 2 comments
based on this advice from /r/golang
I believe the biggest way to improve this would be to rethink your error handling. Error handling in Go is very explicit, and is a first class feature of the language. Some areas to research might be:
-
you use both log.Fatal and explicit fmt.Println followed by os.exit. consider sticking with one.
-
consider only using log.Fatal or equivalent in main. As is, any error calling the webGet function will exit the program. This includes 429’s for API rate limiting, or any other transient issue.
-
consider handling those transient issues, such as a back off for 429 errors. This would be where goroutines would come in useful. They do bring some complexity though, as you would need to consider how to handle reporting errors and status. Goroutines can’t “return” data, and usually send errors and results via a channel, either combined or in separate channels. I recommend Concurrency in Go by Katherine Cox-Buday. Awesome book!
-
the normal pattern for go funcs that can possibly error is to return (type, error) where type is the appropriate type. Some funcs, like your contains can’t really error, but most/all others can. The normal way of handling this is to either handle the error as soon as possible, say by waiting and retrying the operation, or bubbling the error up with some more context. The latest version of Go has new error handling capabilities also, although I don’t think they are necessarily needed here.