Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

doc/articles/wiki: misleading error handling in Writing Web Applications tutorial #18543

nickvellios opened this issue Jan 6, 2017 · 5 comments


Copy link

@nickvellios nickvellios commented Jan 6, 2017

Please answer these questions before submitting your issue. Thanks!

What version of Go are you using (go version)?


What operating system and processor architecture are you using (go env)?

GOGCCFLAGS="-fPIC -m64 -pthread -fno-caret-diagnostics -Qunused-arguments -fmessage-length=0 -fdebug-prefix-map=/var/folders/c9/n428syrn3xl63_wf458yzw9w0000gq
/T/go-build862609477=/tmp/go-build -gno-record-gcc-switches -fno-common"

What did you do?

On line 66 of this example:
If ExecuteTemplate begins to write to the http.ResponseWriter before an error is thrown, http.Error will not properly return an error to the user.

New Gophers will see this (as I did) and assume ExecuteTemplate will never write to the buffer if an error is thrown. This is not correct.

Example case:

What did you expect to see?

Write to a temporary buffer first, if no error is caught then write that to the http.ResponseWriter.

What did you see instead?

http.Error(w, err.Error(), http.StatusInternalServerError)

Copy link

@dsnet dsnet commented Jan 6, 2017

Seems like a reasonable change to the example. I've been bitten by this mistake before as well.

A part of me wonders how expensive it would be for template to do up-front error-checking to ensure that it never starts writing unless it knows it will encounter no template issues.

@dsnet dsnet added the NeedsFix label Jan 6, 2017
@dsnet dsnet added this to the Unplanned milestone Jan 6, 2017
@dsnet dsnet changed the title Writing Web Applications tutorial - Improper error handling doc/articles/wiki: misleading error handling in Writing Web Applications tutorial Jan 6, 2017
Copy link

@nickvellios nickvellios commented Jan 10, 2017

dsnet, good question. Without an intimate understanding of the underlying template package I have some doubts. If templates are parsed ahead of time and it can be ensured that variable nil pointer exceptions and the like don't throw a panic, it may be doable with minimal overhead.

Copy link

@kisielk kisielk commented Jan 11, 2017

It's probably a bad idea to encourage printing the error from the template engine to the client in the first place. That seems like something that should be logged and a generic error message sent with the 500 response. Maybe that's getting too deep for the example though :)

Copy link

@nickvellios nickvellios commented Jan 11, 2017

Agreed. However, I wonder where that line should be drawn between a production level example and easy to follow teaching material. Maybe a part 1 with the basics and part 2 showing how to secure it is overdue. From reading many of the requests on /r/golang I can see web app curiosity is strong.

Copy link

@kisielk kisielk commented Jan 11, 2017

Yeah, it's probably out of scope of this issue.

As it stands, the whole "Error handling" section of that document is incorrect because it's supposed to demonstrate returning an error to the client if there is a problem with the template execution, but it will in fact return http.StatusOK since the write has already begun. That can easily be fixed by the use of a buffer.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
None yet
Linked pull requests

Successfully merging a pull request may close this issue.

None yet
4 participants
You can’t perform that action at this time.