On Sun, Feb 21, 2021 at 9:23 AM robert engels <reng...@ix.netcom.com> wrote: > > Can someone please explain the benefit of ‘error return’ over ‘checked > exceptions’ ? I have made the point a few times and it goes to crickets - I > have to believe that is because there is none, or it is difficult to > communicate.
As I wrote earlier, I believe that experience shows that it is extremely difficult to write a large scale program with multiple maintainers that uses checked exceptions. In practice, programs always fall back to unchecked exceptions. So I would say that one benefit of error return over checked exceptions is simply that error returns scale to large programs and many maintainers. Another benefit is described by Rob's blog post, which I'm sure you've seen: Errors are values (https://blog.golang.org/errors-are-values). More generally, errors are not exceptional conditions. They are part and parcel of how programs work. They are part of the normal program flow, and they should be part of that flow. They shouldn't be regarded as exceptional and unusual flow. I'm not going to claim that any of these benefits are slam dunks. If there were obvious solutions to how to handle errors, nobody would still be discussing different approaches. But I am claiming that Go's approach to error handling has real benefits. > The ‘handle where they occur claim’ is weak, as you can handle exceptions at > the call site with similar LOC and constructs - but why when in most cases > (of non-trivial software) the error value is just returned up. No offense to > Wojciech - the rpc transport layer doesn’t do the retires, it passes up an > error, and a higher level performs retry logic, if all retries fail, it will > pass up another error that the rpc failed, etc. This pattern is used > throughout well designed software. If you hard using this pattern you are > creating very hard to maintain software. I can't agree that in most cases the error is just returned up. I would agree that within a single package an error is often (but not always) returned up without change. But in large Go programs that I've seen, when error values cross package boundaries, they are almost always annotated with additional information. > Checked exceptions are ‘error values’ with more information (e.g stack > traces, causes, etc.), and can be enforced by the compiler (declared) and > inspected by modern IDE’s for code complete. ‘error returns’ have none of > these features. The only valid claim is that they are more expensive than > error values, BUT you should not be using exceptions - or error values - for > flow control. This is the fundamental problem to me with Go’s error handling > - the flow control and errors are mixed leading to very difficult code to > read & validate that all potential paths are handled now and in the future. My opinion, which contradicts yours, is that when the flow control is written down on the page, as it is in Go, the flow is easy to read, and it is much easier to check that all potential paths are handled. With exceptions the control flow is not written down, so it is easier to miss cases where an exception can arise. With exceptions the normal control flow is easier to see, but the error control flow is harder. And since the error control flow happens less frequently, it's more important to make it clearly visible to the original programmer and, more importantly, to the future maintainer. Again, no slam dunks here. Reasonable people can disagree. But I think the Go position is entirely defensible for large scale programs with many programmers. Ian -- You received this message because you are subscribed to the Google Groups "golang-nuts" group. To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/golang-nuts/CAOyqgcW2uhrVv%2Br9Z1AdQdzGZN9JnRBWsZ6CoAQ0dg46RZGpCA%40mail.gmail.com.
