Not surprisingly, I completely disagree. While this individual line of code may seem particularly offensive, it was written that way to be extremely clear and m

Not surprisingly, I completely disagree. While this individual line of code may seem particularly offensive, it was written that way to be extremely clear and minimize dependencies. A more structured web app would be doing much more with the error depending on the situation. I'm glad that the code to handle those errors would be right around the logical point it should be: where I'm performing the action. Many of the handlers have some boiler plate error checking on some actions that could fail. I agree those lines of code are repetitive and aesthetically displeasing, but as I alluded to in the article, a more filled in app could define a handler type that returns an error instead of being expected it to handle it within. The http.Error calls would change to returns, but that's a good thing: a quick scan allows me to see when the function can return to the caller. I don't have to inspect every line of code and remember details about which calls throw exceptions or not. Nothing is hidden, and the code does exactly what it says on the page. Give me a slightly more verbose but clear code base than a terse one with spooky action at a distance any day.