Whereas it doesn't bother me at all. I've used Go for years now and it feels totally normal to check the error condition after every call. It feels strange switching to JS and there's just nothing - stuff can just error at any time and we're not going to do anything about it? That feels odd ;)
You can - one can put an exception handler at the place one truly wishes to handle the error as opposed to always introducing repetitive code at every single place in the call chain.
The latter tends to make the eyes glaze over in tedium after some time and due to the signal/noise ratio one misses real bugs in the error handling.
>You can - one can put an exception handler at the place one truly wishes to handle the error as opposed to always introducing repetitive code at every single place in the call chain.
I don't understand this point but I hear it raised often. At best I'm lukewarm on Go's error handling. Having if err != nil feels the same to me ergonomically as a try / catch.
For a lot of complicated programming you can be 20 levels deep in function/method calls and most of the time you deeply don't care and you want to crash out to the main loop which will then either decorate the error for the user and crash itself or clean things up and loop if it can.
Then there's exceptional exceptions which should be not crash near the "edge" of the program and need to be caught and something done with, so you add those to the program.
What you wind up with using that approach is only exception handling being written where you need it, and the vast bulk of the code is understood to always crash and get handled in some inner loop, or even some external supervisor.
Go feels like it was a reaction to (probably early-2000s) Java programming patterns where at every level Java programs were catching and decorating and rethrowing their own exceptions. Neither of those approaches really are helpful though because you litter your code with all kinds of exception handling that nobody really cares that much about, and under both systems you can crash instead of retrying and all the useless error handling code you've written everywhere doesn't help you see where you've made that error. The 2010 erlang crash-first programming mentality works way better imo rather than error checking everywhere.
And Go out of the box makes it difficult to get stack traces, so you should really use an error library at least.
The number of JS scripts I've had to add any error handling to is too damn high.
I like that Go forces at least some kind of error handling.
The "signal/noise ratio" problem fades after a while - you start seeing "if err != nil {...}" as a single statement after a while, a steady rhythm in the code. You notice when it's not there, or when it's doing something different.
