>>106269364
>try catch is infinitely easier to read than if err != nil
This is such a retarded talking point. Even the Golang designers finally decided to completely abandon the project to add syntactic sugar around the standard error handling. That's how much a non-issue it is.
You would know why if you've ever programmed anything serious, but I'm happy to explain.
First, why do you think Golang is used a lot on the backend, in cloud environments, for networking, distributed systems, etc. In other words, in environments where you CONSTANTLY have errors of various kind: network, timeouts, DNS, file system, etc.
Isn't that an apparent contradiction? Why would you use the language with supposedly the "worst" error handling, in environments where you have the most errors?
The obvious answer is that in such environments you actually have to handle errors anyway, you can't just catch at the top level and log it, like a Pajeet would do. In which case, most of the time is spent writing the actual error-handling logic, and the syntactic details of explicit vs. exception-handling are essentially irrelevant.
I write Golang for a living, writing large-scale distributed systems. My error handlers retry SQL queries with extra diagnostics, record various statistics and metrics, upload various diagnostic files to S3 buckets for further investigation, and so on. So the distinction of
>if err != nil {
vs.
>try { } ... catch {}
is completely irrelevant.
