[xa0s]

Wprowadzam goroutines to mojego projektu i chciałbym się dowiedzieć czy dobrze to zrobiłem :) https://pastebin.com/jmKyZeyk

Wydaje mi się, że jest to źle, szczególnie z tymi errorami. Nie wiem jak to ugryźć.
#go #golang

[shdw]

@xa0s: w taki sposób w jaki to napisałeś, jeżeli SaveMovie zwróci błąd, to będziesz miał deadlock. Przerzuc wg.Done() z linii 7 do linii 2 i zamień na defer wg.Done().

[shdw]

@xa0s: możesz też zrobić decoupling tej metody od WG, bo nie ma potrzeby zeby ona o tym wiedziała.

https://pastebin.com/fY88g0jF

[xa0s]

@shdw: Dzięki wielkie, teraz ma to sens i dużo lepiej wygląda :D. Mam jeszcze jedno pytanie. Jak ta goroutine jest w pętli for i wywala mi error, to jest opcja, żebym kontynuował pętle ?

[shdw]

@xa0s: nie bardzo rozumiem pytanie. Samo tworzenie goroutines się nie wywali, więc pętla na pewno dojdzie do końca. Ale raczej nie o to pytasz.

[xa0s]

@shdw: Chodzi mi to to, że mam funkcję s.update(video) w goroutine i ona może wywalić błąd. Czy jest opcja, żeby kontunować wykonywanie tej pętli gdy wystąpi error? Coś w stylu, żeby w linii 23 wstawić continue

[shdw]

@xa0s: to są oddzielne wątki, jeden nie wywali drugiego. Dodatkowo w Go wszystkie błędy są obsługiwane ręcznie, więc to nie Ty musisz dodać continue, tylko Ty musiałbyś dodać break. Chyba, że mówisz o możliwym panic, wtedy wypadałoby go obsłużyć, bo niewyłapany panic wywali ci cały główny proces.

https://pastebin.com/PWXCNkKt

Dodatkowo wszystkie goroutines są spawnowane jedna po drugiej w pętli, więc najpierw zostanie stworzone X wątków, a pozniej zacznął się

[kontra]

@xa0s: dorzuce jeszcze od siebie jak czytelnie pisac obsluge bledow i flow logiki kodu. Chodzi mi o linie 3-9 z Twojej pierwszej wklejki, czyli if err == nil { ... if err == nil { ... } }
Polecam ten artykul na temat "happy path" w kodzie i dlaczego utrzymywanie logiki biznesowej przy lewej stronie (a bledow w prawo) ulatwia czytanie kodu - https://medium.com/@matryer/line-of-sight-in-code-186dd7cdea88

[xa0s]

@shdw: O coś takiego mi właśnie chodziło, dzięki za pomoc.
@kontra: Wiem, że tak nie powinno się robić, tylko nie widziałem jak obsłużyć błąd w goroutine, dlatego tak to zrobiłem. Mimo tego dzięki, za link do artykułu, z chęcią poczytam.

[kontra]

tylko nie widziałem jak obsłużyć błąd w goroutine

@xa0s: czasem ludzie tworza kanal ktorym przesylaja bledy do glownego procesu, robi sie to wtedy troche podobne do zwracania bledow z goroutines tak jak z funkcji. Ale to troche antywzorzec. Bardziej idiomatycznym sposobem na ogarniecie tego jest pakiet errgroup.

https://godoc.org/golang.org/x/sync/errgroup

Errgroup dziala praktycznie tak samo jak waitgroup, z tym ze pozwala na proste zwracanie i obsluge bledow. Jedyna roznica w uzytkowaniu to

[xa0s]

@kontra: Nie widziałem, że coś takiego istnieje. Dzięki wielkie za pokazanie tego.