> The fact is, 99% of programs need only one exception handler.
Maybe if you just write high level business logic and something else already handles exceptions for you. I think my Java code typically has 70% of the exceptions handlers that I also would need in Go. Need to close upstream connections, release resources like buffers, etc. If it’s not catch blocks, then it’s at least a finally block. And often it’s also a good idea to catch and transform an exception, so that the calling code doesn’t need to deal with exceptions that come from pure implementation details.
The parent implied that in exception based languages you can save all the boilerplate since exceptions just propagate. My statement here was that I don’t think this is true, since you still need to do error handling (and have error awareness), eg for resource cleanup during those.
I am very aware about try with resources. It works however only if the lifetime of objects are tied to a scope.
* The overwhelming vast majority of functions do not allocate resources that need to be explicitly cleaned up.
* Cleanup is no more painful with exceptions - try/finally is not materially different from defer.
* In any language, a healthy pattern is "if you allocate it, you clean it up". This pattern in Go and Java looks basically the same.
* Go's lack of exceptions mean that you pay the penalty of error handling on every function call, not just in the tiny fraction of a fraction of a percentage of function calls that allocate resources.
* For business processing... this is just a non-issue, full stop. There's generally only one resource that gets allocated - a transaction - and it gets cleaned up automatically on exceptions. All that noise in Go is an utter waste of time.
Maybe if you just write high level business logic and something else already handles exceptions for you. I think my Java code typically has 70% of the exceptions handlers that I also would need in Go. Need to close upstream connections, release resources like buffers, etc. If it’s not catch blocks, then it’s at least a finally block. And often it’s also a good idea to catch and transform an exception, so that the calling code doesn’t need to deal with exceptions that come from pure implementation details.