The code should at least log the error because it means there is something wrong somewhere, eventhough you can't do much about it it helps understand some other issues.

The only way to log the error is to handle it in Go.

The code should throw away the data it read from the connection just before it closed it, because there's a high chance of it being corrupt.

That's just crazy. How do you define "just before" ?

The last iteration before the current check. But I'd assume the foolproof way would be to return an error if the Close() returns an error, erroring out the entire read. I don't know if a partial read is ever a good thing.

What if it is a write?

That complicates things, but no different from seeing an error either way. The point is that checking for an error at point one is not enough, if you want to be sure there wasn't an error you need to check point 2 as well.

In the case of a write, if you seen the success message at point 1 you might not care about a failure at point 2, because you already know the write was a success, assuming your confirmation at point 1 was explicit and well formed.

In the case of read, say you read an email address, and received '[email protected]'. The thing is, if the connection was cut you don't know if that address was supposed to be '.com', '.co.in' or '.co'. The only way you can tell in the current MySQL protocol is to check for an error on point 2 (the Close()). If you see an error, you know the read was incomplete, and you throw it away. If you don't check, you might have read the wrong (corrupt) value.