7

Goland shows a underline in a err variable without explaining why/no tooltip for the underline cause (see image below -- the arrow points to the weird underline). the code in Goland, with err underlined

Does anyone know the cause for the underline?

(It does not seem to be because the err is defined a few lines above because I have similar err reuse in other files and there is no underline in them).

Here is the code, although this question would make no sense without an explaining picture from the IDE because this seems to be a bug in Goland.

package mypack

import (
    "fmt"
    "os"
)

func SomeFunc() (string, error) {
    err := GetSomething()
    if err != nil {
        return "", fmt.Errorf("some err")
    }

    currentDirectory, err := os.Getwd()
    if err != nil {
        return "", fmt.Errorf("error getting current dir. %v", err)
    }

    return currentDirectory, nil
}

func GetSomething() error {
    return nil
}
E_net4
  • 27,810
  • 13
  • 101
  • 139
JonyD
  • 1,237
  • 3
  • 21
  • 34
  • 2
    First, post the code and not a screenshot of it. Second, it's better to post a [mcve] than just some fragments of the code. – icza Nov 18 '20 at 11:32
  • 5
    Considering the question is about a visual effect of an IDE, an image makes sense to me. – Jonathan Hall Nov 18 '20 at 12:28
  • @icza you completely misunderstood his question. He is asking why the ide creates a visual artifact. A screenshot is the most reasonable and probably only way to present the question. – Charlie Flowers Feb 20 '22 at 01:17

1 Answers1

10

The underlined variable is not an indicator of an error. GoLand is informing you that you are re-assigning the err variable.

You first create the variable here:

err := GetSomething()

And then you re-assign the same variable in that line:

currentDirectory, err := os.Getwd()

And that is why the err is underlined. Not an error, just something to make this more obvious to you.

Sometimes, it is undesirable to re-assign variables, because it can have unwanted side-effects.

In this particular case, I think it is a common Go pattern to have a single err variable and re-use it throughout a function/method.

Jens
  • 20,533
  • 11
  • 60
  • 86