소켓 연결을 열면 소켓 열기 후에 즉시 socket.Close() 논리를 지연 함수에 넣습니다. 그러나 socket.Close()가 또 다른 공포를 일으키는 경우에는 어떻게 될까요? 내 프로그램이 충돌하지 않도록하기 위해 항상 다른 지연/복구를 내포해야합니까? 이런 식으로 뭔가 : http://play.golang.org/p/GnEMQS-0jjGolang에서 안전한 연결 닫기
감사합니다, Elgs
일반적으로 당신이 패닉에 대해 많이 걱정 할 필요가 없습니다. 일반적으로 개발자 실수 (nil 참조, 배열 범위 외)와 시스템 레벨 오류 (메모리 부족과 같은)는 크게 두 가지 오류 유형을 나타냅니다.
다른 사람이 말한대로 socket.Close은 당황하지 않으며 오히려 오류를 반환합니다. 수행 할 경우 :
defer socket.Close()
오류는 무시되며 다른 작업은 필요하지 않습니다.
그러나 공황 상태에서 복구하고 싶다고 가정 해보십시오. 당신이 복구 핸들러가 먼저 연기되는 경우에는 다른 작업을 수행 할 필요가 없습니다
func main() {
defer func() {
if err := recover(); err != nil {
fmt.Println(err)
}
}()
defer panic("this will be recovered")
}
이연 기능은 역순으로 실행됩니다 : http://golang.org/ref/spec#Defer_statements
이연 기능은 주변 직전에 실행됩니다 함수는 거꾸로 된 순서대로 반환합니다.
socket.Close()는 패닉 IIRC를 일으킬 수 없습니다. – fuz
잘 모르겠습니다 : 닫기 (예 : net.TCPConn)로 인해 오류가 발생할 수 있지만 당황하지는 않습니다. 만약에 그것이 당황하면, 예를 들면. 하드웨어 손상이나 메모리 부족으로 인해 어쨌든 앱이 날아갑니다. 귀하의 경우에 따라 반환 된 오류를 처리하는 것이 좋지만 Close에서 패닉을 처리하는 것은 약간 편집증적인 것 같습니다. – Volker
@FUZxxl 서버에서 연결을 거부하는 클라이언트 소켓을 닫으려고 할 때 패닉이 발생합니다. 소켓을 패닉없이 닫을 수 있는지 여부를 알 수있는 방법이 있습니까? 또는 소켓 닫기 논리에 대해 한 단계 더 지연을 중첩시켜야합니까? –