<p>Examples I've found for the http Server.Shutdown method (new in go 1.8) do an abrupt panic or exit if ListenAndServe returns an error other than http.ErrServerClosed (for example, see the code below). </p>
<p>This is fine if you shut down in response to an os.Interrupt signal (i.e. it won't be called). But what if ListenAndServe terminates for some other reason? Might there not be requests still in progress? Shouldn't you wait for them (e.g. by uncommenting the commented-out Shutdown in the code below)?</p>
<pre><code>func main() {
http.HandleFunc("/", func(w http.ResponseWriter, r *http.Request) {
log.Println("Handler start.")
time.Sleep(5 * time.Second)
log.Println("Handler end.")
})
srv := &http.Server{Addr: ":8081"}
go func() {
done := make(chan os.Signal)
signal.Notify(done, os.Interrupt)
<-done
srv.Shutdown(context.Background())
}()
err := srv.ListenAndServe()
if err != nil && err != http.ErrServerClosed {
// srv.Shutdown(context.Background())
log.Fatalf("ListenAndServe error - %v", err)
}
}
</code></pre>
<hr/>**评论：**<br/><br/>ChristophBerger: <pre><p>I guess the reason lies in the "crash early" principle. If a process triggers unexpected errors, it may have gone into an unspecific state. Letting it continue to run may cause more damage (such as writing wrong data into the database) than crashing right away. </p></pre>georgekong: <pre><p>I suppose it's application-dependent. I'm inclined to give my handlers the benefit of the doubt and let them finish.</p></pre>
