I see a lot of code do this kind of thing:
log.Fatal(http.ListenAndServe(":8080",nil))
I have never seen the http server return an error, but I would like to understand more about the possibility what types of failure scenarios I can encounter.
Will it stop if my handler code panics? Will it only return in the case where it can't bind initially?
What is the best practice for making sure the server stays active to the highest degree possible?
Will it stop if my handler code panics?
No. The built-in http server recovers from panics and logs them.
Will it only return in the case where it can't bind initially?
That's the usual reason, though it's possible that some other error could force the listener to close.
What is the best practice for making sure the server stays active to the highest degree possible?
If the http server's main loop exits, it's likely a fatal error that you don't want to try and recover from. If that call returns when trying to bind the address, you could check for the address in use error, then wait and try again.
// Example to show the error types and fields on a *nix system.
// You should check the validity of these assertions if you don't want to
// panic. Due to the fact that this reaches into syscall, it's probably
// not much better than checking the string for "address already in use"
if err.(*net.OpError).Err.(*os.SyscallError).Err == syscall.EADDRINUSE {
fmt.Println("Address in use")
}
Remember that ListenAndServe is actually 2 calls, and you can separate them yourself. It creates a net.Listener, then gives it to an http.Server's Serve(l net.Listener) method.
It may be worth noting that the go package documentation for log.Fatal says
Fatal is equivalent to Print() followed by a call to os.Exit(1).
Also, the documentation for http.ListenAndServe explains that
This function will block until the program is terminated.
So the log.Fatal call will only be made if the http listener is killed for some reason.
A panic will be handled, as the answer above says.
The http.ListenAndServe function should continue indefinitely until the underlying socket connection is broken. At that point log.Fatal will print any message returned by the listener, before calling the program to exit completely with an error code (1).
So the "best practice" to keep the listener alive would be to do anything that keeps the socket connection alive. At that stage, it's more likely to be a network consideration.