Please provide a full program to reproduce this.

Also, try building your program with -race. Most memory corruption issues with Go are because the program is racy or uses unsafe in an incorrect way.

Hi @mvdan thanks for the quick response!

I've created a short program to illustrate the issue: https://play.golang.org/p/QwbR7J99nZs

nil pointer dereference

You're trying to read from a nil reader. This is very much expected. Wrap your code with a nil check.

The Go project doesn't use the issue tracker for questions. See https://golang.org/wiki/Questions.

Thanks for pointing that out @mvdan . Although this wasn't intended to be a question. I'm already using a nil check in my code, but felt this behavior could be included in the go standard library.

Unless the docs explicitly say that they handle a nil interface value, you can't assume it will work. Passing nil to Decode makes little sense in any case, and isn't documented to work, so a panic seems fine to me. Adding extra code to specifically handle this case and return it as an error seems to have no benefit in my eyes.

One case where this would be helpful: validating JSON data sent to REST APIs. Supposing the handler received an empty request body, and passes it into Decode. Currently, the handler needs to perform error check twice, like so:

func createSample(w http.ResponseWriter, r *http.Request) {
	if r.Body == nil {
                // error handling
        }
        var s Sample
	res, err := json.NewDecoder.Decode(&s)
	if err != nil {
		// error handling
	}
}

Yes, and that seems fine to me. Because "no input was provided" is an entirely different error than "there was a problem decoding the JSON".