Dnia Sat, 27 Apr 2013 10:50:45 -0500 po głębokim namyśle A.L. rzekł:

> On Sat, 27 Apr 2013 12:28:05 +0000 (UTC), Edek
> <e...@g...com> wrote:
>
>>angielka ;). Teoria rozproszonych procesów ma spójny model, model jaki
>>znam nie zakłada istnienia wyjątków, bo łatwiej mieć implementację
>
> Jaka teoria? Prosze byc konkretnym i podac zrodla.

Wystarczą wstępy tych dwu prac:
http://venus.vmars.tuwien.ac.at/documents/extern/182
2/RR-2006-007-conf.pdf
https://ecommons.library.cornell.edu/bitstream/1813/
6208/1/94-1426.pdf

>>Wyroczni niż przekazywać sygnalizację o błędach pomiędzy procesami
>>bezpośrednio (pomijając błędy w danych i inne nie wynikające z
>>przypadkowych błędów hardware czy crasha procesu).
>>
> Nie rozumiem.

Teoretycznie rozpatruje się algorytm uzyskania Consensusu mając
"possibly weak failure detector". Mając nie program na desktopie
ale wiele maszyn czy bardziej teoretycznie procesów realizujących
algorytm jest to najlepsze znane - mi znane - podejście do
rozwiązania problemu nieuniknionych wad sprzętu i komunikacji
w rozproszonym systemie na temat zarówno propagowania informacji
o błędach jak i treści samego algorytmu rozproszonego. Split-brain
syndrome jest trywialnym przykładem problemu.

Tłumacząc mi chodzi o to, że programiści powinni się skupiać
na problemie do rozwiązania - i tu nie mam wiele przeciwko wyjątkom
- a nie na problemach typu "które z moich rozproszonych algorytmów
trafiło na uszkodzony właśnie node".

>>Jakie są merytoryczne argumenty za stosowaniem wyjątków w systemach
>>rozproszonych procesów?
>
> Takie same jak za posiadaniem hamulca w samochodzie. A konkretnie:
>
> 1. Proces to zwyczajny sekwencyjny program. Wyjatki sa potzrebne aby
> obsluzyc sytuacje wyjatkowe i aby w takich sytuacjach proces po prostu
> nei "padl". Jednym z elementow takiej obslugi jest powiadomienie
> kooperujacych procesow o problemie
> 2. Procesy kooperujace musza wiedziec ze komus w tej grupie cos nie
> poszlo i odpowiednio zareagowac
>
> Wyjatki da sie pzresylac kanalami, jak najbardziej. Robi to na przykald
> Erlang, ktory powiadamia kooperujace procesy o wyjatku i przyczynei
> wyjatku.

Zgoda, że istnieje konieczność obsługi błędów. Błędów różnej natury.
Zgadzam się też, że wyjątki da się przesłać kanałem. Pytanie jest
inne: dlaczego udostępniać tą cechę w języku? Dlaczego rozprzestrzeniać
informację o błedach wyjątkami?

> Gdy dobieram sie do Prologu z Javy przy pomocy kanalu, wyjatek rzucony w
> Prologu samoczynnie konwertuje sie w wyjatek po stronie Javy.

Super, nic nowego, Web serwisy też to robią. Tyle że proces rozproszony
nie jest już procesem sekwencyjnym więc nie rozumiem co konwersja
wyjątków ma do tego - da się, ok, wiemy.

> Jezyk bez wyjatkow to samochod bez hamulcow. Co w zasadzie mozna
> pomyslec, bo dawno temu hamulce w samochodach byly takie sobie (patrz
> WItold Rychter, "Moje Dwa i Cztery Koka", cytat: "I wlasnie zjezdzajac
> moja Tatra z Morskiego Oka pokazalem ze samochod wcale nie musi meic
> hamulcow". Ale dzisiaj takiego wyczynu by nie dokazal).

Fajna anegdota i metafora. A bardziej merytorycznie? Błędy sygnalizować
można różnie, nie tylko wyjątkami.

> Pomijam inne "nowalijiki" GO w rodzaju braku dziedziczenia. Ale to temat
> na osobny watek

--
Edek