See below: > On Feb 21, 2021, at 3:17 PM, Ian Lance Taylor <i...@golang.org> wrote: > > 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. > I don’t think answering, “people fall back to unchecked exceptions” is an answer to “how do error returns and checked exceptions differ”.
> 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. > Yes, with all due respect to Rob, we'll probably disagree on that blog post. Take the Scan() example. This is a justification of how to write code that isn’t painful when you don't have exceptions - instead it puts the burden on the writer of Scan() to set a boolean internally to ‘don’t do anything’, write an additional method Err(), check the boolean on all other methods, etc., then the caller needs to remember to call Err() after all processing - and the code might loop through a billion elements doing nothing - potentially creating huge inefficiencies. Lastly, a reader of the code where the developer had failed to call Err() would not know unless they were intimately aware of the particular API - this is not good for long term maintenance. I can provide examples for each case in the blog as to why it seems more 'defensive justification’ rather than evidence of being better. > 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. > > There is no difference between if err != nil { return someWrappingMethod(err) } and catch (SomeException e) { throw SomeOtherException(e); } but, if you don’t want or can’t provide additional information you don’t need to do anything, BUT you still have to declare that your method throws the exception - this is an important benefit. and if you have several methods or loops that throw the exception you can move the handler to outside - in Go this is plain tiresome and ugly - the blog post tries to handle this with the Scan() and ErrWriter() - again - not handling the errors as they occur (so no, Go code doesn’t ‘read’ linearly - many of the LOC may become noops interspersed with other non-noop code which is a nightmare). Exceptions as advanced error values as more benefits: 1. the developer needs to declare what exceptions the method throws if any - this is unbelievably valuable for efficient development and maintenance - rather than trying to read through documentation (hopefully up to date) or code to try and figure out all of the possible errors a method will return and what they mean 2. the ‘value’ of an exception contains a lot more information by default - often no need to wrap, as the stack trace provides sufficient information, and a ‘developer label’ can easily become out of date >> 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. > I agree. I still believe that ‘checked exceptions’ are just ‘better error values’. As to ‘unchecked exceptions’ Go falls back on unchecked exceptions all over the place - otherwise the it would be incredibly painful for the developer to check every allocation or memory access. Regardless, I don’t think Go can afford to rely on third-party packages for something as critical as error handling. These packages, even if limited, need to be made part of the core stdlib in order to facilitate easier long-term maintenance. These packages can be viewed as ‘exceptions light’ or ‘better errors’. So even if Go needs to pick it now, something is better than nothing (and increased fragmentation). R > 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/5AADD753-20C0-4C2B-90AE-4CEBFD5A1FB6%40ix.netcom.com.
