Re: [go-nuts] Which error handling pattern do you prefer?

On Friday, November 12, 2021 at 6:29:46 PM UTC-5 michael...@gmail.com wrote: > FWIW (which may not be much) I've settled on explicitly naming my return > values in the function declaration. If the function returns include an > error, I name always name it err. The general pattern is > > func

Re: [go-nuts] Which error handling pattern do you prefer?

FWIW (which may not be much) I've settled on explicitly naming my return values in the function declaration. If the function returns include an error, I name always name it err. The general pattern is func foo() (v someType, err error) { err = doSomething() if err != nil { err =

Re: [go-nuts] Which error handling pattern do you prefer?

Nice, make it simple. On Friday, November 12, 2021 at 3:08:31 PM UTC+8 axel.wa...@googlemail.com wrote: > I don't prefer either. I decide on a case-by-case basis. I generally > ignore the question of scope, though. The relevant question (to me) is > readability. If the statement is short, I

Re: [go-nuts] Which error handling pattern do you prefer?

On Fri, Nov 12, 2021 at 7:48 AM Miguel Angel Rivera Notararigo < ntr...@gmail.com> wrote: > I tend to use errX (X is adapted according to context) for function scoped > errors, and err for block scoped errors > > func MyFunc() error { >> v, errDS := doSomething() >> ... >> errDA :=

Re: [go-nuts] Which error handling pattern do you prefer?

I tend to use errX (X is adapted according to context) for function scoped errors, and err for block scoped errors func MyFunc() error { > v, errDS := doSomething() > ... > errDA := doAnotherthing() > } > if err := doAnotherthing(); err != nil { > return err > } > That way you don't

Re: [go-nuts] Which error handling pattern do you prefer?

`I do find this rather annoying, to the point where I'll stick a "var err error" at the top of a function rather than have the first assignment be different to the subsequent ones. ` I think this is a good way. I usually code in this way if there're multiple error assignments. If each error

Re: [go-nuts] Which error handling pattern do you prefer?

Oh, I have a typo error, in the second pattern, `err := doAnotherthing()` should be `err = doAnotherthing()`. On Friday, November 12, 2021 at 4:02:34 PM UTC+8 Brian Candler wrote: > func MyFunc() error { > v, err := doSomething() > ... > err := doAnotherthing() > } > > That won't compile

Re: [go-nuts] Which error handling pattern do you prefer?

func MyFunc() error { v, err := doSomething() ... err := doAnotherthing() } That won't compile anyway; the second assignment would have to be err = doAnotherthing() See: https://play.golang.org/p/pvNC7YHI88j I do find this rather annoying, to the point where I'll stick a "var err

Re: [go-nuts] Which error handling pattern do you prefer?

I don't prefer either. I decide on a case-by-case basis. I generally ignore the question of scope, though. The relevant question (to me) is readability. If the statement is short, I use the one-line version, otherwise (or if I need to use either result after the conditional) I use the version with

[go-nuts] Which error handling pattern do you prefer?

Hi, guys, I want to know which error handling pattern do you prefer. Following is a code snippet from go stdlib. https://sourcegraph.com/github.com/golang/go/-/blob/src/net/http/h2_bundle.go?L1848 Let me simplify my questions: Pattern1: like the code in go stdlib, in the same function, we