sundq
sundq

Reputation: 763

how to golang check a variable is nil

my code is like this, when I use req, _ := http.NewRequest("GET", "http://www.github.com", content), it will emit exception:

panic: runtime error: invalid memory address or nil pointer dereference
[signal 0xb code=0xffffffff addr=0x0 pc=0xaab78]

goroutine 1 [running]:
net/http.NewRequest(0x34f3b8, 0x3, 0x378020, 0x15, 0xfeec4350, 0x0, 0x10738801, 0x0, 0x0, 0x107000e0)
    /usr/local/go/src/net/http/request.go:570 +0x498
main.main()
    /tmp/sandbox056954284/main.go:17 +0xe0

but when I use req, _ := http.NewRequest("GET", "http://www.github.com", nil), it works, why? how I set the third argument value

package main

import (
    "bytes"
    "net/http"
)


func main() {
    client := &http.Client{}
    var content *bytes.Reader
    content = nil
    req, _ := http.NewRequest("GET", "http://www.github.com", content)
    resp, _ := client.Do(req)
    defer resp.Body.Close()
}

Upvotes: 7

Views: 30914

Answers (3)

tangxinfa
tangxinfa

Reputation: 1500

It is a classic trap of the golang language.

To check if it is a real Nil:

p == nil || reflect.ValueOf(p).IsNil()

Reference: https://www.mangatmodi.com/posts/go-check-nil-interface-the-right-way/

Upvotes: 3

0x434D53
0x434D53

Reputation: 1463

A go interface consists of a type and a value. An interface is only nil if both the type and the value are nil. You provided a type but no value: Therefore NewRequest tried to call Read on a nil struct (the value of the interface).

Upvotes: 8

David Budworth
David Budworth

Reputation: 11626

content is nil by default, don't need to assign it

also, you are ignoring the error returned from NewRequest, don't do that. It is telling you why it can't generate a request.

Normal error handling would be something like:

req, err := http.NewRequest("GET", "http://www.github.com", content)
if err != nil {
  // log or complain... req is nil here
} else {
  // do something with req
}

all that said if you really just want to know if req is nil, do:

if req == nil { 
 // handle nil req
} else {
 // use req
}

but as mentioned before, it's much better to handle the error. if err not nil, then you basically can't trust req to be anything valid.

Upvotes: 3

Related Questions