In most traditional languages nowadays, you write a try-catch block.
If any error happens in that entire try block, you catch it at one place with whatever granularity you want, handle it once and then you move on. You write a try-catch around blocks of your code so you can rest easy that if there is any kind of error, at least you will get notified. You will know. You will print the stacktrace.
Not so with Golang. In Golang you have to write an if clause for every single function call that can return errors and that’s a lot of them. You have to print any information that you want to know in every single if clause manually.
So if you make 5 api calls, you have to write 5 if clauses manually, print out where the error occurred and generate some kind of stacktrace yourself. This is 5 times more code than in a language that has proper exceptions.
Lets say you fopen a file and it fails and you ignored the error with _ then how do you find out? Answer: When something that depends on the success value attempts to access it. Yes exactly, so instead of catching the error when you actually expect it you now get an unexpected side effect error down the line somewhere else and need to spend x10 the time to find the original source of the error. Don’t tell me you never had to track down the real source of an error before, well that’s what potentially happens on every single function call in golang that you didn’t meticulously check and manually handle the potential error codes for.
How is that better than just having exceptions? It’s not. It really just isn’t.
