Re: [go-nuts] Avoiding http: multiple response.WriteHeader calls

1,135 views
Skip to first unread message

Andy Balholm

unread,
Nov 11, 2014, 1:49:41 PM11/11/14
to u89...@gmail.com, golan...@googlegroups.com

> On Nov 10, 2014, at 11:15 AM, u89...@gmail.com wrote:
>
> Hello, quick question, why doesn't calling http.Error not end the current request (in other words, how do I end the current request without having to specifically "return" from the dispatcher below)?

Calling http.Error doesn’t end the current request because the http package doesn’t hijack the control flow of your handler at any point. From when your handler gets called till when it returns, it is in full control of what happens. This is mostly a good thing, but it means that you need to take responsibility for exiting your handler when errors are found.

u89...@gmail.com

unread,
Nov 11, 2014, 4:19:09 PM11/11/14
to golan...@googlegroups.com, u89...@gmail.com
Thanks Andy but by doing so the only way to abort the request would be from the handler. Functions called from the handler (that have access to w/r) can't abort the request in any way (thus forcing the way the handler code is written). Having a function called Error that does nothing beyond setting an error code is rather useless in my opinion and would rather be called something else. I think Error should hijack and give application programmers an easy way out.

James Bardin

unread,
Nov 11, 2014, 4:50:25 PM11/11/14
to golan...@googlegroups.com, u89...@gmail.com


On Tuesday, November 11, 2014 4:19:09 PM UTC-5, u89...@gmail.com wrote:
Thanks Andy but by doing so the only way to abort the request would be from the handler. Functions called from the handler (that have access to w/r) can't abort the request in any way (thus forcing the way the handler code is written). Having a function called Error that does nothing beyond setting an error code is rather useless in my opinion and would rather be called something else.

It's useful because setting an error code and writing a short message is very common. http.Error is just a small convenience function, and If you need something slightly different it's only 3 lines of code. 
 
I think Error should hijack and give application programmers an easy way out.

If you hijack the connection, you prevent the server from re-using it or possibly completing other pipelined requests. 
Also, how else would you end the control flow in the handler function without a return? (besides panic)

 
Reply all
Reply to author
Forward
0 new messages