Po otwarciu połączenia przez gniazdo natychmiast odłożę logikę socket.Close() w funkcję odroczenia po otwarciu gniazda. Co jednak, jeśli socket.Close() spowoduje kolejną panikę? Czy zawsze powinienem zagnieżdżać inne opóźnienie/odzyskać wewnątrz zewnętrznego opóźnienia, aby zapobiec awariom mojego programu? Coś takiego: http://play.golang.org/p/GnEMQS-0jjBezpieczne, bliskie połączenie w Golang
Dzięki Elgs
Generalnie nie trzeba się martwić o wiele paniki. Zwykle reprezentują dwie klasy błędów: błędy programistów (zerowe odniesienia, tablica poza granicami) i błędy na poziomie systemu, na których prawdopodobnie nie można wiele poradzić (np. Brak pamięci).
Jak powiedzieli inni, socket.Close nie wpadnie w panikę, a raczej zwróci błąd. Jeśli to zrobisz:
defer socket.Close()
Błąd zostanie odrzucony i nie trzeba wykonywać żadnych innych czynności.
Ale przypuśćmy, że chcesz wyjść z paniką. Jeśli jesteś obsługi odzyskiwania jest odroczona pierwszy wtedy nie trzeba robić nic innego:
func main() {
defer func() {
if err := recover(); err != nil {
fmt.Println(err)
}
}()
defer panic("this will be recovered")
}
odroczonego funkcje są uruchamiane w odwrotnej kolejności: http://golang.org/ref/spec#Defer_statements
odroczonego funkcje są wykonywane bezpośrednio przed otoczeniem funkcja zwraca, w odwrotnej kolejności zostały one odroczone.
socket.Close() nie może wywołać paniki IIRC. – fuz
Nie jestem całkowicie pewny: Zamknij (na przykład net.TCPConn) może spowodować błąd, ale myślę, że nie panikuje. A jeśli wpadnie w panikę, np. z powodu uszkodzenia sprzętu lub braku pamięci aplikacja i tak jest przepalona. W zależności od przypadku możesz chcieć obsłużyć zwrócony błąd, ale obsługa paniki w Close wydaje się nieco paranoidalna. – Volker
@FUZxxl przy próbie zamknięcia gniazda klienta, którego nie chce połączyć się z serwerem, panikuje. Czy istnieje sposób, aby powiedzieć, czy gniazdo można bezpiecznie zamknąć bez paniki. Czy muszę zagnieździć jeszcze jeden poziom odroczenia tylko dla logiki zamykania gniazd. –