Golangs error handling is really annoying. I'm writing a cli that does a bunch of stuff, and a lot of that could cause an error. Now I have to either explicitly ignore the errors everywhere or write an abundant if, that simply checks if the error exists and print it to console. So I either won't see any errors when something goes wrong, or I will have ugly bloated code... wtf, I want "throw" back

New to the go community, do you know if they plan on fixing or improving the error handling?

@Bubbles I'm new as well, I thought that maybe I'm just doing something wrong

@Bubbles I had to write 4 nested ifs because you can't chain methods because of this

@Marl3x I just know it’s one of the bigger complaints I hear about Go, aside from the large binaries and lack of generics

@Marl3x that’s rough buddy

Oh, and there I was thinking that I'll learn Go and be happy about knowing another peice of performant language. Guess not this year.

There are plenty of ways to do it with the conducts go provides. From defer panic recover to closure and handler functions. You just need other design patterns.

I've been using it on one project while reading the go programming book. Apparently early return is the way to go for error so you don't nest too much. At least you know you handled the error.

What I'm not sure I did right yet is returning different type of errors with interface implementing the Error method so I could act according to the error type from the caller side. It felt messy.

Overall, it feels like most functions is 15 lines of error handling and defers for 5 lines of business logic