5 ms·
The tedium of errors irked me for a long time until I realized that it was my poor abstractions inherited from what I learned in other languages that lead to th
by randomdata 5y ago
The tedium of errors irked me for a long time until I realized that it was my poor abstractions inherited from what I learned in other languages that lead to that state. As I established a more Go-minded approach, it became much more pleasant.
To the point that I now find it desirable. I have been on Typescript/Javascript projects of late. Now that's a tedious error handling experience. I notice my colleagues have given up on error handling entirely due to how difficult it is.
- powerslacker 5y agoSame here. The Go approach is easy to read and eye compile. I can't stand exceptions now.
- philosopher1234 5y ago>eye compile i like this phrase
- eweise 5y agoIt still suffers from being returned as a separate value so not easy to chain methods together.
- robotastronaut 5y agoMethod chaining, while possible, isn’t something I’d say is really encouraged in Go. Returned values should be handled explicitly. There are plenty of cases where it could be fine, but if a function can error, you wouldn’t want to chain anyways.
- closeparen 5y agoYes, you would. “Chain all these methods and stop when you get to the first error” is an extremely common idiom. People write it all the time in lots of different languages. Go is unusual in that you have to spell it out.
- robotastronaut 5y agoRight, I know. You’re not wrong. I was meaning you wouldn’t want to do it in Go because it’s not idiomatic (and likely impossible as discussed). I use it all the time in other languages and don’t mind exception patterns, but method chaining feels very out of place when reading Go code.
- threatofrain 5y ago> As I established a more Go-minded approach, it became much more pleasant. Could you explain more by any chance?
- recov 5y agoHere's a good article form rob pike on one way to look at how Go can handle errors https://go.dev/blog/errors-are-values https://go.dev/blog/errors-are-values
- nprateem 5y agoExtra complexity to work around a shortcoming which ignores the fact that most users of a library only care about errors at the top level. Passing errors around manually when the machine could do it is a waste of time however it's dressed up.
- nemothekid 5y ago>Passing errors around manually when the machine could do it is a waste of time however it's dressed up. You, the writer, pass around errors manually so that the reader, who interfaces with the code 10x more than the writer, is able to reason about the code. Go's errors handling sucks, but I don't think everyone has the same opinion on why it sucks; I personally think that sum types should be added to the language making it impossible for errors to be silently ignored. Exceptions, while convenient, require too much discipline to use cleanly.
- nprateem 5y agoSomehow after 25 years of coding I've never seen issues with using exceptions. Java is more explicit, Python gets the job done, and a good IDE helps in most cases anyway
- jatone 5y agoevery java team i've worked with handles their exceptions by making them runtime exceptions to bypassing the very thing you're pro-porting.
- closeparen 5y agoYeah part of the reason it’s so tedious is that our application architecture is always Handler->Controller->Gateway or Repository->External Client, a pattern we first developed for Python. Errors mostly originate in the external clients and then have to be returned through all the layers. When I read open source projects there is a lot more “PHP spaghetti” with business logic and storage interactions right inside handlers, which is indeed easier for error handling, but definitely has other problems.
- mountainriver 5y agoSame, went back to python and I find it terribly annoying. You want to handle your errors, Go makes that simple, lots of other languages don’t
- closeparen 5y ago99.5% of the time I want to return a 500 to the caller. Other languages do that for free. Go makes it very manual.