4 ms·

>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 p

>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. Am I missing something by thinking that?

lamontcg 5y ago
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.

lamontcg 5y ago

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.