Some developers build sheds others build skyscrapers. Exceptions let you build skyscrapers - but not everyone needs a skyscraper.
I’ve use both methods extensively in my career - well written exception code is far easier to write and maintain for more complex systems. > On Feb 20, 2021, at 2:31 PM, Matthew Holiday <matthew.holi...@nytimes.com> > wrote: > > > 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. >>>> >>>> -- >>>> 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. >>> >>> >>> -- >>> 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. > > > -- > 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. -- 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/BB196FAD-91CE-4FED-AD47-ACB1379EBC19%40ix.netcom.com.
