alt Hacker NewsAgreed and even more heretical from me is that I quite like declared exceptions. It makes the interface of a method clear in all the ways it can fail and you can directly choose what to handle often without having to look at the docs to work out what they mean, because the names tell you what you need to know. You can ignore them and rethrow catch globally but you can also handle them.
Having used Go for years now frankly I prefer exceptions, way too often there is nothing that can be done about an error locally but it produces noise and if branches all over the code base and its even worse to add an error later to a method than in Java because every method has to have code added not just a signature change. I really miss stack traces and the current state of the art in Go has us writing code to produce them in every method.
Replies
Go keeps on not adding syntax sugar for if err != nil. https://go.dev/blog/error-syntax
But often the problem of language can be partially solved by IDE. IDE can already generate if err != nil branches. Goland can fold if err != nil branches. https://github.com/golang/vscode-go/issues/2311
Yep, checked exceptions are the shit. You can of course abuse them to create a monstrosity (as you can with anything), but when used responsibly I think they are by far the best error handling paradigm.
> I really miss stack traces
What's to miss? Go has exception handlers and stack traces built-in and has had since day one. Even the standard library does it (e.g. encoding/json), if it is that you were waiting on some kind of "blessed permission" to proceed. Exception handling isn't appropriate for every situation (no tool is appropriate for every situation), but if it is for the kinds of problems you have, use it. The tools are there to use.