-
Data: 2013-04-29 13:29:20
Temat: Re: Co sie tu dzieje?...
Od: Andrzej Jarzabek <a...@g...com> szukaj wiadomości tego autora
[ pokaż wszystkie nagłówki ]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?
Następne wpisy z tego wątku
- 29.04.13 15:03 Edek
- 29.04.13 15:32 Edek
- 29.04.13 16:35 Edek
- 29.04.13 16:29 A.L.
- 29.04.13 17:06 Edek
- 29.04.13 17:27 A.L.
- 29.04.13 17:32 Andrzej Jarzabek
- 29.04.13 17:57 Edek
- 29.04.13 17:51 Stachu 'Dozzie' K.
- 29.04.13 18:15 Andrzej Jarzabek
- 29.04.13 18:28 Edek
- 29.04.13 19:07 Edek
- 29.04.13 19:26 M.M.
- 29.04.13 19:47 Adam Przybyla
- 29.04.13 20:01 A.L.
Najnowsze wątki z tej grupy
- 7. Raport Totaliztyczny: Sprawa Qt Group wer. 424
- TCL - problem z escape ostatniego \ w nawiasach {}
- Nauka i Praca Programisty C++ w III Rzeczy (pospolitej)
- testy-wyd-sort - Podsumowanie
- Tworzenie Programów Nieuprzywilejowanych Opartych Na Wtyczkach
- Do czego nadaje się QDockWidget z bibl. Qt?
- Bibl. Qt jest sztucznie ograniczona - jest nieprzydatna do celów komercyjnych
- Co sciaga kretynow
- AEiC 2024 - Ada-Europe conference - Deadlines Approaching
- Jakie są dobre zasady programowania programów opartych na wtyczkach?
- sprawdzanie słów kluczowych dot. zła
- Re: W czym sie teraz pisze programy??
- Re: (PDF) Surgical Pathology of Non-neoplastic Gastrointestinal Diseases by Lizhi Zhang
- CfC 28th Ada-Europe Int. Conf. Reliable Software Technologies
- Młodzi programiści i tajna policja
Najnowsze wątki
- 2024-11-24 Czy Sejm RP zahamuje proceder zabijania dla organów?
- 2024-11-24 Aby WKOOOORWIĆ ekofaszystów ;-)
- 2024-11-22 OC - podwyżka
- 2024-11-22 wyszedł z domu bez buta
- 2024-11-22 Bieda hud.
- 2024-11-24 DS1813-10 się psuje
- 2024-11-23 Białystok => Inżynier bezpieczeństwa aplikacji <=
- 2024-11-23 Szczecin => QA Engineer <=
- 2024-11-23 Warszawa => SEO Specialist (15-20h tygodniowo) <=
- 2024-11-22 Warszawa => Kierownik Działu Spedycji Międzynarodowej <=
- 2024-11-22 Warszawa => Senior Account Manager <=
- 2024-11-22 Warszawa => Key Account Manager <=
- 2024-11-22 Warszawa => DevOps Specialist <=
- 2024-11-22 Kraków => IT Expert (Network Systems area) <=
- 2024-11-22 Warszawa => Infrastructure Automation Engineer <=