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 foo() (v someType, err error) {
> err = doSomething()
> if err != nil {
> err = fmt.Errorf("some context: %v", err)
> return
> }
> err = doNextThing()
> if err != nil {
> err = fmt.Errorf("some context: %v", err)
> return
> }
> // etc
> return
> }
>
>
As Brian mentioned above, naked return values are generally frowned upon.
You can easily find the arguments if you like, but even the official tour
of go (at https://tour.golang.org/basics/7) says:
"Naked return statements should be used only in short functions, as with
the example shown here. They can harm readability in longer functions."
That's a pretty official caution. Personally, I am very much in that camp.
In my experience, naked returns harm readability in all cases, just less in
short functions.
So this is probably not a good pattern to use as your default one.
> Naming the error solves the initial := problem. As for shadowing, I make
> it a point never to do a := assignment involving err. For example, if I
> need to call os.Open, I do
>
> var f *os.File
> f, err = os.Open(...)
>
> I tend to use other names for errors only when it's something I can fix
> within the local scope.
>
> At first I tried hard to avoid the verbosity. Now I use a few helpful
> snippets to reduce keystrokes and an editor plugin the partially fades any
> block that starts with "if err != nil". The latter works amazingly well
> (for me at least) to reduce visual clutter. I like it much better than one
> I tried that auto-folds error blocks. It made me waste time unfolding them
> to see what was inside :-)
>
> YMMV, of course.
>
> On Friday, November 12, 2021 at 11:15:21 AM UTC-5 david....@gmail.com
> wrote:
>
>> 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 := doAnotherthing()
>>>> }
>>>>
>>>
>>> if err := doAnotherthing(); err != nil {
>>>> return err
>>>> }
>>>>
>>>
>>> That way you don't shadow errors.
>>>
>>
>>
>> I can't +1 this enough.
>>
>> I've caught *so* many bugs from shadowed errors (and re-used error
>> variables). I consider it a rather bad anti-pattern to have a single err
>> variable
>> that's reused throughout a scope.
>> If you have unique error variable names and you forget to do something
>> with an error that you've assigned a name you automatically get unused
>> variable compile-errors. (just this is enough to be worthwhile)
>>
>>
>> With that said, constraining the scope using the initializer statement on
>> an if (or switch) statement suffices when you don't need any other return
>> values, at which point I may use the err variable-name (although I often
>> make those unique for clarity anyway).
>>
>>> --
>>> 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...@googlegroups.com.
>>>
>> To view this discussion on the web visit
>>> https://groups.google.com/d/msgid/golang-nuts/CAF9DLCmR4ZdnVs4A28BSrPcbiHsQ_ufub5cSPjCt2SDy2dA1xA%40mail.gmail.com
>>>
>>> <https://groups.google.com/d/msgid/golang-nuts/CAF9DLCmR4ZdnVs4A28BSrPcbiHsQ_ufub5cSPjCt2SDy2dA1xA%40mail.gmail.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/9789bfb1-1944-4874-b7c6-785e16002been%40googlegroups.com.
