I'm referring to errors found in the function (i.e., by calling other functions). It's the responsibility of the callers of a function to handle the errors it returns, and not the function itself. How can one function claim responsibility for the error handling strategy of all programs using it?
Yes, I suppose in some sense exceptions guarantee all errors are handled somewhere. Unfortunately, what I've seen of exception handling over the years is that it's often "log the stack trace and keep moving", which isn't all that useful, and tends to cover up real bugs. A better approach would be not to catch exceptions at all, and let them crash the program (which is what Go's panic will do); this ensures the bugs are really handled by removing them from the program. [And given this type of exception "handling" it's not much value to the author of a single function to know that the errors will all be "handled" somewhere.] Unfortunately, exception handling languages tend to put all types of errors, normal and abnormal *, into the same basket. Which means you can't do sensible error handling for, e.g., JSON that doesn't decode, while allowing the program to crash when there's a logic bug. (For non-safety critical software, a crash failure is typically the safest way to fail. Safety-critical software, on the other hand, avoids exception handling like the plague.) * A normal error is some behavior that can reasonably be expected, such as "file not found" or "no route to host", etc. Abnormal errors are logic bugs in the program. An aside: Assuming you had a cyclomatic complexity calculator that took exceptions into consideration, such that exceptions passing through a function counted as a branch, what kind of numbers would you get? Probably pretty awful, given just about any line of code would be capable of throwing an exception. But exceptions typically aren't counted, so that functions are thought to be far less complex than they really are in the presence of exceptions. Invisible (magic) return paths through a function go against the notion of "the code does what it says on the page". On Sat, Feb 20, 2021 at 1:11 PM Robert Engels <reng...@ix.netcom.com> wrote: > Can you clarify what you mean mean by “the code does exactly what it shows > on the page”? How do you know by looking at the code, or even compiling the > code, that all possible errors returned by a function are handled? That to > me is biggest difficult in reading (or using) others Go code. Exceptions > (well written) handle this by declaring all possible error (or categories) > thrown by the method. > > This seems a real problem with long term maintenance of Go code. > > On Feb 20, 2021, at 1:39 PM, Matthew Holiday <matthew.holi...@nytimes.com> > wrote: > > > Roger beat me to it. > > But allow me to rephrase, > > "The users of Go for a long time have resisted any changes to its simple, > clear method of error handling despite it being a major concern of folks > who don't use Go much." * > > * I'm referring to the original survey, which was worded along the lines > of "what keeps you from adopting Go?" > (implying that the responders are those who haven't adopted Go) > > Any type of error handling that creates invisible returns in a function is > a bad idea IMNSHO (an opinion backed up by various researches into the > complexity of exception handling). Speaking for myself, I'd like to retain > that quality of Go whereby "the code does exactly what it says on the page." > > > On Sat, Feb 20, 2021 at 11:31 AM roger peppe <rogpe...@gmail.com> wrote: > >> >> >> On Sat, 20 Feb 2021, 16:31 L Godioleskky, <lgod...@gmail.com> wrote: >> >>> Rust lang, very early in its evolution, saw the need to create its >>> operator '?' to more efficiently manage error handling. But the guardians >>> of Go lang have resisted any changes to its clumsy method of error handling >>> despite it being a major concern of Go users for a very long time. >> >> >> Actually the "guardians of Go" (by which I guess you mean the Go team at >> Google) tried quite hard recently to propose an improved way of handling >> errors, but it was resisted by "Go users". So what you're saying is just >> not true, I'm afraid. >> >> >>> >>> On Sunday, February 14, 2021 at 11:14:11 AM UTC-5 ohir wrote: >>> >>>> Dnia 2021-02-13, o godz. 17:44:47 >>>> Michael MacInnis <michael.p...@gmail.com> napisał(a): >>>> >>>> > I've been playing around with reducing error handling boilerplate >>>> >>>> You're not alone. Hundreds of us went into such thinking in the first >>>> weeks >>>> of reading/using Go - yet before we noticed how much more productive we >>>> are with Go's "boilerplate" than we were in languages where handling >>>> errors >>>> (failures) was "a problem of others", including future-us as "others". >>>> >>>> Perceived consensus of the Go community is that "error handling >>>> boilerplate" >>>> is a strong feature. I.e. in normal production software you MUST handle >>>> failures >>>> and you should do it as close as possible to the source of said >>>> failure. >>>> >>>> Go helps with that. Even team's proposal was finally retracted: >>>> https://github.com/golang/go/issues/32437 Discussion there is lengthy, >>>> but worth >>>> reading to sense why wider community considers "boilerplate" as asset. >>>> >>>> Error handling proposals umbrella: >>>> https://github.com/golang/go/issues/40432 >>>> >>>> > Michael. >>>> >>>> Hope this helps, >>>> >>>> -- >>>> Wojciech S. Czarnecki >>>> << ^oo^ >> OHIR-RIPE >>>> >>> -- >>> 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/2b2b2ecc-18e6-4e4c-b71c-581d6ff0fc16n%40googlegroups.com >>> <https://groups.google.com/d/msgid/golang-nuts/2b2b2ecc-18e6-4e4c-b71c-581d6ff0fc16n%40googlegroups.com?utm_medium=email&utm_source=footer> >>> . >>> >> -- >> 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/CAJhgacim5uPaik2_QxgafB5uZ589ojWmbFdy54U6etHn4x5z0g%40mail.gmail.com >> <https://groups.google.com/d/msgid/golang-nuts/CAJhgacim5uPaik2_QxgafB5uZ589ojWmbFdy54U6etHn4x5z0g%40mail.gmail.com?utm_medium=email&utm_source=footer> >> . >> > > > -- > *Matt Holiday* > Senior Gopher, Marketing Technologies > > 620 Eighth Avenue > > New York, NY 10018 > > matthew.holi...@nytimes.com > > -- > 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/CAGSa1C%3DyS48YXZ95ut_LaEiBU2MKCKF5pERgkW5q7%2BHVFv4Stw%40mail.gmail.com > <https://groups.google.com/d/msgid/golang-nuts/CAGSa1C%3DyS48YXZ95ut_LaEiBU2MKCKF5pERgkW5q7%2BHVFv4Stw%40mail.gmail.com?utm_medium=email&utm_source=footer> > . > > -- *Matt Holiday* Senior Gopher, Marketing Technologies 620 Eighth Avenue New York, NY 10018 matthew.holi...@nytimes.com -- 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/CAGSa1Cnc_%2BXFRE%3DKW6J%3DPUc39UGF4aD%2BBCSBpnHVF2i0Ceg22Q%40mail.gmail.com.
