6 ms·
Sure it works fine until you start multithreading, where handling an exception doesn't end with unwinding the stack, because there are multiple stacks. So then
by cle 7y ago
Sure it works fine until you start multithreading, where handling an exception doesn't end with unwinding the stack, because there are multiple stacks. So then have to pass it as a value to some other thread's stack, and remember to catch it in every thread or else your thread will silently die. But then you're right back to where Go is: treating errors as values.
- apta 7y agoAt least you can't mistakingly ignore errors, unlike in a lot of golang code I've seen where errors are either ignored, or worse, silently overwritten.
- lenkite 7y agoYou simply have a single uncaught-exception handler and that takes care of the problem that you mention. Instead of 500,000 if err != nil checks littering the source code and making functions unreadable.
- cle 7y agoI’m well aware of how to deal with the problems created by unchecked, stack-unwinding exceptions. The thing is, when I’m reading Go code, I can look at a call site and easily know if an error can occur and what happens to the error (including if it’s sent to another goroutine), using very simple and consistent mechanisms. The tradeoff is verbosity, but it is worthwhile verbosity IMO because it’s simple, consistent, explicit, and does not create the unnecessary coupling of checked exceptions. I appreciate this low cognitive overhead when I go back to a codebase 6 months later, or when onboarding a new hire.