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
}
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/6b493efc-79ad-43f7-8730-91abd9b6c9cfn%40googlegroups.com.
