3 ms·
But the flow of the program isn't only or primarily about the happy path. I find it annoying when languages that don't force explicit error handling choices, fo
by zaphar 5y ago
But the flow of the program isn't only or primarily about the happy path. I find it annoying when languages that don't force explicit error handling choices, force me to go searching for the non-happy path. Where do they handle the errors at? It's nowhere in this pull request. Are there errors to handle? You have to assume there must be because exceptions. Then I have to write a bunch of comments asking if they know whether this line can throw or not. Usually the answer is "I don't know" and then I'm the annoying one in the PR review because I tell them to please find out and either add a comment or handle/wrap the exception appropriately.
If the only thing you care about is the happy path in your review then Go code will annoy you. But you are also only doing half of your job in that review.
- simiones 5y agoIn exception-safe code, you don't care if a particular statement can throw - if the code is correct today when some line can't throw, it should still be correct tomorrow when that line can throw. Also, it's much easier to look for catch{} blocks than it is to look for Go code that actually handles errors, since code that forwards errors, code that wraps errors, and code that handles errors all looks more or less the same in Go (if err != nil {...}).