Question

我看到很多代码做了这样的事情：

log.Fatal(http.ListenAndServe(":8080",nil))

我从未见过http服务器返回错误，但我想了解更多关于我可以遇到哪种类型的故障情况的可能性。

如果我的处理程序代码恐慌，它会停止吗？它只会在最初无法绑定的情况下返回吗？

确保服务器尽可能保持活动状态的最佳做法是什么？

Answer 1

如果我的处理程序代码恐慌，它会停止吗？

没有。内置的http服务器从恐慌中恢复并记录它们。

它只会在最初无法绑定的情况下返回吗？

这是通常的原因，尽管其他一些错误可能会迫使听众关闭。

确保服务器尽可能保持活动状态的最佳做法是什么？

如果http服务器的主循环退出，则可能是您不想尝试从中恢复的致命错误。如果在尝试绑定地址时该调用返回，您可以检查address in use错误，然后等待再试一次。

// 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")
}

请记住，ListenAndServe实际上是2次调用，您可以自己分开。它会创建net.Listener，然后将其提供给http.Server的{{1}}方法。

Answer 2

值得注意的是log.Fatal的{{3}}代表

致命等同于Print（），然后调用os.Exit（1）。

此外，http.ListenAndServe的{{3}}解释了

此功能将一直阻止，直到程序终止。

因此只有在http侦听器由于某种原因被杀死时才会进行log.Fatal调用。

如上面的答案所说，将会处理恐慌。

http.ListenAndServe函数应该无限期地继续，直到底层套接字连接断开。此时log.Fatal将打印侦听器返回的任何消息，然后调用程序完全退出并显示错误代码（1）。

因此，保持监听器活着的“最佳实践”是做任何使套接字连接保持活动的事情。在那个阶段，它更有可能成为网络考虑因素。

在什么情况下http.ListenAndServe将返回

2 个答案: