I don't believe anyone is talking about not handling errors. There are functions that perform a sequence of actions and need to go no further when an error is encountered. An example of this type of function is presented in the "Errors are Values" post:
https://blog.golang.org/errors-are-values Another example is the CopyFile function from "Error Handling - Problem Overview": https://github.com/golang/proposal/blob/master/design/go2draft-error-handling-overview.md In these cases the caller may be better equipped to know what to do next when there is an error. The "Errors are Values" post gives some examples of using the language to simplify error handling. The check/handle and try proposals do the same thing but by proposing language changes. I don't believe any of them are proposing not checking and/or not handling errors. I can tell you most emphatically that I am not proposing not checking and/or not handling errors. I'd like to know if, for functions like the ones just mentioned, a pattern exists for "eliminating much of the boilerplate that arises if every error is checked with a rote if statement." And further if that pattern can be implemented as a library/package with acceptable trade offs. Michael. On Saturday, February 20, 2021 at 6:54:39 PM UTC-5 ohir wrote: > Dnia 2021-02-20, o godz. 13:21:09 > Michael Ellis <michael...@gmail.com> napisał(a): > > > FWIW, I've put together a tiny package that, with some tradeoffs, seems > > useful for reducing boilerplate in the common case where a function > simply > > wants to return an error to its caller. > > > The code is almost trivial. It consists of two small functions, > > ro.RecoverOn( err *error) and ro.ReturnOn(err error), used as follows: > > > in the common case where a function simply wants to return an error to > its caller. > > There is no trade off here for me (an likely many others). It is idiomatic > versus weird: > > 1. hit !er<space> move on coding (in fact MY shortcut puts panic instead > of return). > > 2. USE: import (write) a module, setup defer stack, confuse first-time > reader, write a call, move on. > > Note that both versions on my vim take just one line off the screen > estate. This is true for any IDE able to fold. OK - idiomatic would take > two lines more if code is viewed in pager or using MS Word. > > > in the common case where a function simply wants to return an error to > its caller. > > It is NOT a "common" case. > > In the "boring" production code we are expected that any service exposed > to the end-user will never refuse to work, our code must try really hard to > complete, retrying at other server here, then at other city's or continent > server room until its real task can be successfully done. Resources (eg. > network services) needs to be acquired, then vetted, then operated on, then > finally released in a consistent state. > > So we don't throw "something went wrong" (ie. unhandled exception) up. Nor > we do "Return if any error". We do check errors, then > retry in loops. Go explicit, IN PLACE handling helps with that alot. > > TC, > > -- > 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/c54ded01-20af-4a92-b10c-f85438ed136bn%40googlegroups.com.
