英文:
Golang: Is a network condition can make a net/http HandleFunc to panic?
问题
你现在是我的中文翻译，代码部分不要翻译， 只返回翻译好的部分， 不要有别的内容， 不要回答我要翻译的问题。以下是要翻译的内容：
想象一下，我有一个关键的函数，应该要么全部运行，要么不运行。
TakeMoneyFromSomeone()
GiveMoneyToSomeoneElse()
我的问题是：当使用net/http.HandleFunc时，我能相信Go语言在第1行和第2行之间不会发生panic吗？（这两个函数在我的HTTP处理程序内部）
我只关注网络问题。例如：如果客户端断开连接、超时、请求体过长或其他任何问题。是否存在任何网络问题会导致服务器在第1行和第2行之间发生panic？（这两行代码没有使用网络）
如果答案是否定的，那么如果我尝试向已关闭连接的客户端进行ResponseWriter.write操作，会发生什么？会发生panic吗？
英文:
Think about that I have a critical function, that should run all or nothing.
TakeMoneyFromSomeone()
GiveMoneyToSomeoneElse()
My question is: Can I trust Go that the function will not panicing between line1 & line2 when using `net/http.HandleFunc? (The two function are inside my http handler)
I'm focusing only on networking issues. For example: if the client disconnect, or timeout or too long body, or anything else. There is any networking issue that can make the server panic between line1, and line2? (Those two lines not using network)
If the answer is no. What happened if I try to ResponseWriter.write to a client that closed the connection. Is it will panic?
答案1
得分: 2
HandlerFunc本身与任何潜在的网络问题无关，它只是将处理程序注册到URL模式中。
HandlerFunc
如果设置为0超时，它将会挂起而不是引发panic。更好的方式是使用超时并处理错误，而不是使用默认的超时设置。
> 通过创建自定义服务器，可以更好地控制服务器的行为：
s := &http.Server{
Addr: ":8080",
Handler: myHandler,
ReadTimeout: 10 * time.Second,
WriteTimeout: 10 * time.Second,
MaxHeaderBytes: 1 << 20,
}
log.Fatal(s.ListenAndServe())
而且你不应该从内置库中恐慌。
> panic通常意味着出现了意外错误。我们通常使用它来快速失败处理在正常操作中不应该发生的错误，或者我们没有准备好优雅地处理的错误。
>
> 注意，与某些使用异常处理许多错误的语言不同，在Go中，习惯上尽可能使用指示错误的返回值。
英文:
The HandlerFunc itself doesn't related to any potential networking issues, it just registers handlers to url patterns.
HandlerFunc
With 0 timeouts it will hang not panic. The better way is to use timeouts and handle errors instead of using default timeouts.
> More control over the server's behavior is available by creating a custom Server:
s := &http.Server{
Addr: ":8080",
Handler: myHandler,
ReadTimeout: 10 * time.Second,
WriteTimeout: 10 * time.Second,
MaxHeaderBytes: 1 << 20,
}
log.Fatal(s.ListenAndServe())
And you shouldn't apprehend a panic from a built-in libs.
> A panic typically means something went unexpectedly wrong. Mostly we use it to fail fast on errors that shouldn’t occur during normal operation, or that we aren’t prepared to handle gracefully.
>
> Note that unlike some languages which use exceptions for handling of many errors, in Go it is idiomatic to use error-indicating return values wherever possible.
通过集体智慧和协作来改善编程学习和解决问题的方式。致力于成为全球开发者共同参与的知识库，让每个人都能够通过互相帮助和分享经验来进步。
评论