On Sun, Feb 21, 2021 at 3:01 PM robert engels <reng...@ix.netcom.com> wrote: > > > 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”.
But that isn't the question you asked. I was trying to answer the question quoted above: "Can someone please explain the benefit of ‘error return’ over ‘checked exceptions’ ?" My answer to this new question "how do error returns and checked exceptions differ” would be one about visible control flow. > I can provide examples for each case in the blog as to why it seems more > 'defensive justification’ rather than evidence of being better. We disagree. > 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 As I've said a couple of times, I don't think this works in actual practice for large programs with multiple authors. Those programs wind up falling back to unchecked exceptions, and this advantage is lost. I don't consider this to be a controversial opinion; a number of people have pointed this out. > 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 Sure, that is both an advantage and a disadvantage (a disadvantage because it means that you pay a cost for every error, and that cost may not be appropriate in all cases). 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/CAOyqgcURf_mBRO0isfh-i-x0ch24eBG7Q-nMGMtk32%3DgkOsqEA%40mail.gmail.com.
