> Terminate processing and pass the error back up the call chain. This is basically what exceptions do, and basically what 'if err != nil { return err }' does.

The function in question that could return an error is being called in the main function. Who are you going to pass it to, exactly? error is a not a return value on main. If you knew what the error could be, you might find a suitable workaround under those conditions. But since the error does not even exist for you to handle, about all you can do is terminate the application. Which is exactly what will happen in this circumstance anyway, even if you don't check the error result.

I'm still not clear what you are really going to meaningfully do with the error information here even if you did magically start getting errors against the compatibility promise? If you are going to handle errors, you actually have to know what you want to do with them. The following adds nothing to your code.

    if err != nil {
        // I didn't expect that. Oh well.
    }

It's not like anyone is suggesting you should avoid checking errors in all circumstances. We're talking about very specific cases where all of the conditions are known. If GET stops being an HTTP request method, or http://example.com/ is no longer a valid URL, you've got way bigger problems than not gracefully handling the world flipping upside down.

> The function in question that could return an error is being called in the main function. Who are you going to pass it to, exactly?

The operating system: exit with a non-zero exit code, indicating the specific error.

Which is exactly what will happen as the code is written.