Why doesn't the Go compiler treat non-declared variable as error?

I've been writing a test program to assist in learning Go. While doing so, I've encountered a few instances where I thought the compiler should have detected an error. I've encountered another similar situation, so I thought I should ask why this situation is not treated as an error.

Example situation :

if oError = rwfile.WriteLines(asParams, sParamsFilename); oError != nil {
    fmt.Printf("Error on write to file Params. Error = %s\n", oError)
} else {
    println("Params file write OK")
}

In the example above, whether or not the variable "oError" is declared, the compiler does not indicate an error. It also works if the line contains the following when the variable is not declared (as expected):

if oError := rwfile.WriteLines(asParams, sParamsFilename); oError != nil {

If I declare the variable "oError", then ":=" does not work (as expected).

"rwfile" is a package that I have written, and the function in question starts as follows:

func WriteLines(asBuff []string, sFilename string) error { // write text file

If I create an error with the write of the file, and use "=" without declaring the variable "oError", the program works correctly and detects the non-nil "oError" variable.

So, why is use of "=" in the above not treated as an error when oError is not declared a variable?

The Go version is go1.1.2 Windows/386.

This means that you have an variable named oError elsewhere in the package. (Note that this variable need not be in the same file; it could be in a different file with the same package clause.) So, when you use oError = ..., you're assigning a value to that package variable, and when you use oError := ..., you're declaring a local variable that hides the package variable. (Per the specification, "An identifier declared in a block may be redeclared in an inner block. While the identifier of the inner declaration is in scope, it denotes the entity declared by the inner declaration." [link])

If you try a different identifier, a unique one, you should see that the compiler indeed complains.

<p>It's unrelated to the actual question, but go fmt can really help with tracking errant stuff in a big program.</p>
<p>Also, following the style guidelines really helps: use terse code styles (no hungarian variable names! took me ages to get used to short names) and short files: a 2Kloc file is probably too big. It's massively worth taking a wander through the standard library source code to see what good Go code looks like</p>