> Very noisy Are you really claiming this under a goddamn Go thread where every third line is error handling? > Do not survive network boundaries Well, depen

> Very noisy Are you really claiming this under a goddamn Go thread where every third line is error handling? > Do not survive network boundaries Well, depends on what you mean here. Do you mean something like RPC? Because there are implementations that can throw an exception for that. I fail to see how is it different with returning an error value, that doesn’t survive network boundaries in itself either. I fail to come up with any example where exceptions are worse than error return types in the context of threads. come on, exceptions give you a stack trace with the whole history of what got called from where. How is that worse than your “file missing” error without any explanation? > easy to ignore Checked exceptions are a thing. But it is enough to handle them higher up and it will be handled one way or another, while it is much easier to simply fail to handle an err. > in practice, rarely handled I can just as well claim that go-style error handling is more often then not not handling properly the issue at hand, and is most definitely not tested for the error case. A bubbled up exception stopping the program/at least a given thread handling a request is a much better outcome then silent failure. > poor quality messages They get as high or low quality messages as one wants. I prefer a proper stacktrace with line numbers over a single obscure line I might occasionally be able to debug by grepping a code base.