On Apr 29, 12:02 am, Edek <e...@g...com> wrote:
> Dnia Sun, 28 Apr 2013 20:04:00 +0100 po głębokim namyśle Andrzej Jarzabek
> rzekł:
> > On 28/04/2013 01:21, Edek wrote:
[...]
> Nie, nie było bez związku. Zacznę od drobnego framentu: wyjątki. Co
> już A.L. uznał za opary absurdu, w rozproszonym procesie o błędzie
> trzeba czasami powiadomić kilka innych Procesów [1]. I tu jest

No ale wyjątki (takie jak w Javie czy C++) nie służą do powiadamniania
procesów. Jeśli trzeba powiadomić procesy, to kod, który to robi
możesz mieć w catch.

> idealny przykład dlaczego Go jest dostosowane do systemów
> rozproszonych: ma defer, panic, recover.
>
> Różnica ze względu na rozproszoną architekturę jest taka, że
> wyjątek łapie się w jednym miejscu, a defer-panic-recover pozwalają
> ręcznie przekazać informację o błędzie w wielu kierunkach. Oprócz
> tego panic() jest jak throw, recover() jak catch(), a defer()
> jak finally; tylko dużo elegantsze. Panic() zwija stos jak throw.

W takim razie przepraszam bardzo. Moja teza była taka, że wyjątki są
przydatne, a nie że Go jest be, bo nie ma wyjątków. Doczytałem o panic
i recover i jak dla mnie są to po prostu wyjątki, tylko troszeczkę
inaczej zrobione. Z tego co przeczytałem jest to ficzer dodany do
języka w późniejszym etapie i sądzę, że narzekanie, że nie ma wyjątków
raczej pochodzi z czasu, kiedy nie było.

Jeśli chodzi o to, co panic/recover wnoszą do rozproszonej
architektury, to przykro mi, ale nie widzę różnicy. W dodatku z
wykorzytsaniem w kontekście współieżności nie wydają się wnosić zbyt
wiele w stosunku do wyjątków, bo z tego co wyczytałem to wyjście z
goroutine w stanie spanikowanym wywala cały program.

Interesującą różnicą między tradycyjnymi wyjątkami a panic/recover
jest "dynamiczny" charakter tych drugich. Jak rozumiem defer/recover
można rejestrować np. warunkowo w klauzuli if. Czy to dobrze czy źle,
nie mam szczególnie zdania: widzę potencjalne problemy z czytelnością,
łatwością wnioskowania p programie, wykrywaniem błędów i
refaktoryzacją, w dodatku "tradycyjne" podejście oparte o zakresy
wydaje mi się elegantsze. Być może natomiast panic/defer/recover mają
jakieś ciekawe idiomatyczne sposoby stosowania, które może nawet
jeszcze nie są odkryte. Po prostu nie wiem.

Niepokojące natomiast są argumenty ze strony projektantów języka typu
"tak, wiemy, że (cośtam w) panic/recover jest kijowe. Specjalnie
zrobiliśmy kijowe, żebyście nie używali panic."

> Znowu tylko fragment: finally-clause vs. defer. Defer mnie się bardziej

Ach, ale akurat to, czy wyjątki są dobre, czy niedobre to jest
oddzielny temat od tego, czy sprzątanie zasobów przez finally jest
dobre czy niedobre. Są języki, które mają inne rozwiązania rtego
problemu, i nawet w samej Javie da się stworzyć (i tworzy się)
odpowiednie wrappery.

> Potem, w Go switch + przekazanie błędu kanałem pozwala w kilku
> linijkach propagować błędy pomiędzy Procesami, co w przypadku
> wyjątków _zawsze i wszędzie_ jest kłopotliwe, nawet w C++11.

Takie rozwiązanie, jak daje ci go, czyli złapać wyjątek w wątku, który
go rzucił i przekazać jako wynic coroutine to z grubsza tak samo
możesz zrobić w C++ przy pomocy future, try/catch, i pair.

[...]
> jedynie w postaci haseł. W zasadzie rozwinąłem się tu tylko
> o wyjątkach - "dlaczego niby miałyby być potrzebne i w którą stronę
> ma wyjątek polecieć, jeżeli jest kilka kanałów?". A że może

No więc dokładnie w taką stronę, w jaką mu exception handler każe
polecieć. Dokładnie tak jak z panic w Go.

> Z generykami jest jeszcze lepiej, zwłaszcza tymi z Javy.

Po przyjrzeniu się wygląda trochę tak, jakby w Go interfejsy dawały
generyczność - przynajmniej taką jak w Javie, a może nawet trochę
mocniejszą. Nie mam racji?