Może monada kontra wyjątki

Zastanawiam się, jakie są zalety Maybe monady nad wyjątkami? Wygląda na Maybeto, że jest to po prostu jawny (i zajmujący mało miejsca) sposób try..catchskładni.

aktualizacja Pamiętaj, że celowo nie wspominam o Haskell.

Użycie Maybe(lub jego kuzyna, Eitherktóry działa zasadniczo w ten sam sposób, ale pozwala zwrócić dowolną wartość zamiast Nothing) służy nieco innym celowi niż wyjątki. W kategoriach Java przypomina to sprawdzony wyjątek, a nie wyjątek środowiska wykonawczego. Reprezentuje ona coś oczekiwanego które masz do czynienia, zamiast błędu nie spodziewał.

Tak więc funkcja indexOftaka zwróciłaby Maybewartość, ponieważ oczekujesz możliwości, że elementu nie ma na liście. Przypomina to powrót nullz funkcji, z wyjątkiem bezpiecznego typu, który zmusza cię do załatwienia nullsprawy. Eitherdziała w ten sam sposób, z tą różnicą, że możesz zwrócić informacje związane z przypadkiem błędu, więc jest to bardziej podobne do wyjątku niż Maybe.

Jakie są zalety podejścia Maybe/ Either? Po pierwsze, jest to obywatel pierwszej klasy tego języka. Porównajmy funkcję używającą Eitherdo zgłaszania wyjątku. W przypadku wyjątku jedynym realnym wyjściem jest try...catchstwierdzenie. W przypadku tej Eitherfunkcji można użyć istniejących kombinatorów, aby uczynić kontrolę przepływu bardziej przejrzystą. Oto kilka przykładów:

Po pierwsze, powiedzmy, że chcesz wypróbować kilka funkcji, które mogą powodować błędy w szeregu, dopóki nie otrzymasz takiej, która tego nie robi. Jeśli nie otrzymasz żadnego bez błędów, chcesz zwrócić specjalny komunikat o błędzie. Jest to w rzeczywistości bardzo przydatny wzór, ale korzystanie z niego byłoby okropnym bólem try...catch. Na szczęście, ponieważ Eitherjest to po prostu wartość normalna, możesz użyć istniejących funkcji, aby uczynić kod znacznie wyraźniejszym:

firstThing <|> secondThing <|> throwError (SomeError "error message")

Innym przykładem jest posiadanie opcjonalnej funkcji. Załóżmy, że masz kilka funkcji do uruchomienia, w tym jedną, która próbuje zoptymalizować zapytanie. Jeśli to się nie powiedzie, chcesz, aby wszystko inne działało tak czy inaczej. Możesz napisać kod coś takiego:

do a <- getA
   b <- getB
   optional (optimize query)
   execute query a b

Oba te przypadki są wyraźniejsze i krótsze niż użycie try..catch, a co ważniejsze, bardziej semantyczne. Używanie funkcji podobnej do <|>lub optionalsprawia, że ​​twoje intencje są znacznie bardziej przejrzyste niż używanie try...catchzawsze do obsługi wyjątków.

Pamiętaj również, że nie musisz zaśmiecać kodu liniami takimi jak if a == Nothing then Nothing else ...! Istotą leczenia Maybei Eitherjak monady jest, aby tego uniknąć. Możesz zakodować semantykę propagacji w funkcji wiązania, aby uzyskać bezpłatne sprawdzanie wartości null / error. Jedyne, co musisz jawnie sprawdzić, to czy chcesz zwrócić coś innego niż Nothingpodane Nothing, a nawet wtedy jest to łatwe: istnieje kilka standardowych funkcji bibliotecznych, które poprawią ten kod.

Wreszcie kolejną zaletą jest to, że typ Maybe/ Eitherjest po prostu prostszy. Nie ma potrzeby rozszerzania języka o dodatkowe słowa kluczowe lub struktury kontrolne - wszystko to tylko biblioteka. Ponieważ są to po prostu wartości normalne, upraszcza to system typów - w Javie musisz rozróżniać typy (np. Typ zwracany) i efekty (np. throwsInstrukcje), których nie używasz Maybe. Zachowują się również tak samo, jak każdy inny typ zdefiniowany przez użytkownika - nie ma potrzeby wprowadzania specjalnego kodu obsługi błędów do języka.

Kolejną wygraną jest to, że Maybe/ Eithersą funktorami i monadami, co oznacza, że ​​mogą skorzystać z istniejących funkcji kontrolujących monadę (których jest sporo) i ogólnie grać ładnie z innymi monadami.

To powiedziawszy, są pewne zastrzeżenia. Po pierwsze, ani Maybenie Eitherzastępuj niezaznaczonych wyjątków. Będziesz potrzebować innego sposobu radzenia sobie z takimi rzeczami, jak dzielenie przez 0, po prostu dlatego, że każdy pojedynczy podział zwróci Maybewartość.

Innym problemem jest zwracanie wielu rodzajów błędów (dotyczy to tylko Either). Z wyjątkami możesz rzucać różne typy wyjątków w tej samej funkcji. z Either, dostajesz tylko jeden typ. Można to obejść za pomocą podtypów lub narzędzia ADT zawierającego wszystkie różne typy błędów jako konstruktorów (to drugie podejście jest zwykle stosowane w Haskell).

Mimo wszystko wolę podejście Maybe/, Eitherponieważ uważam, że jest prostsze i bardziej elastyczne.

1. Wyjątek może zawierać więcej informacji o źródle problemu. OpenFile()może rzucać FileNotFoundlub NoPermissionlub TooManyDescriptorsitp Żaden nie prowadzi tej informacji.
2. Wyjątków można używać w kontekstach, w których brakuje wartości zwracanych (np. W przypadku konstruktorów w językach, które je mają).
3. Wyjątek pozwala bardzo łatwo wysyłać informacje do stosu, bez wielu if None return Noneinstrukcji typu.
4. Obsługa wyjątków prawie zawsze ma większy wpływ na wydajność niż tylko zwracanie wartości.

5. Co najważniejsze, wyjątek i monada Może mają różne cele - wyjątek jest używany do oznaczenia problemu, a być może nie.

   „Siostro, jeśli w pokoju 5 jest pacjent, czy możesz poprosić go, aby zaczekał?”

   • Może monada: „Doktorze, w pokoju 5 nie ma pacjenta”.
   • Wyjątek: „Doktorze, nie ma miejsca 5!”

   (zauważ „jeśli” - to znaczy, że lekarz spodziewa się monady Może)

„Może” nie zastępuje wyjątków. Wyjątki mają być stosowane w wyjątkowych przypadkach (na przykład: otwieranie połączenia z bazą danych, a serwera db nie ma, chociaż powinno być). „Może” służy do modelowania sytuacji, w której możesz mieć lub nie mieć prawidłową wartość; powiedzmy, że otrzymujesz wartość ze słownika dla klucza: może istnieć lub nie - nie ma nic „wyjątkowego” w żadnym z tych wyników.

Popieram odpowiedź Tichona, ale myślę, że jest bardzo ważny praktyczny punkt, którego wszyscy brakuje:

1. Mechanizmy obsługi wyjątków, przynajmniej w językach głównego nurtu, są ściśle powiązane z poszczególnymi wątkami.
2. EitherMechanizm nie jest sprzężony z gwintem na wszystkich.

Tak więc w dzisiejszych czasach widzimy, że wiele rozwiązań programowania asynchronicznego przyjmuje wariant Eitherstylu obsługi błędów. Zastanów się nad obietnicami Javascript , jak szczegółowo opisano w dowolnym z tych linków:

• http://12devs.co.uk/articles/promises-an-alternative-way-to-approach-asynchronous-javascript/
• http://www.html5rocks.com/en/tutorials/es6/promises/
• http://www.toptal.com/javascript/javascript-promises
• https://spring.io/understanding/javascript-promises

Koncepcja obietnic pozwala pisać kod asynchroniczny w następujący sposób (wzięty z ostatniego linku):

var greetingPromise = sayHello();
greetingPromise
    .then(addExclamation)
    .then(function (greeting) {
        console.log(greeting);    // 'hello world!!!!’
    }, function(error) {
        console.error('uh oh: ', error);   // 'uh oh: something bad happened’
    });

Zasadniczo obietnica to obiekt, który:

1. Reprezentuje wynik obliczeń asynchronicznych, które mogły, ale nie zostały jeszcze zakończone;
2. Pozwala na połączenie kolejnych operacji do wykonania na jego wyniku, które zostaną uruchomione, gdy ten wynik będzie dostępny, a których wyniki z kolei będą dostępne jako obietnice;
3. Umożliwia podłączenie modułu obsługi błędów, który zostanie wywołany w przypadku niepowodzenia obliczenia obietnicy. Jeśli nie ma procedury obsługi, błąd jest propagowany do późniejszych procedur obsługi w łańcuchu.

Zasadniczo, ponieważ natywna obsługa wyjątków języka nie działa, gdy obliczenia odbywają się w wielu wątkach, implementacja obietnic musi zapewniać mechanizm obsługi błędów, a te okazują się być monadami podobnymi do typów Maybe/ Eithertypów Haskella .

System typu Haskell będzie wymagał od użytkownika potwierdzenia możliwości a Nothing, podczas gdy języki programowania często nie wymagają wychwycenia wyjątku. Oznacza to, że w czasie kompilacji będziemy wiedzieć, że użytkownik sprawdził, czy nie wystąpił błąd.

Być może monada jest w zasadzie taka sama, jak w przypadku głównego języka stosowanie sprawdzania „null oznacza błąd” (z tym że wymaga sprawdzenia wartości null) i ma w dużej mierze te same zalety i wady.

Obsługa wyjątków może być prawdziwym problemem dla faktoringu i testowania. Wiem, że Python zapewnia ładną składnię „z”, która pozwala wychwytywać wyjątki bez sztywnego bloku „try ... catch”. Ale na przykład w Javie wypróbuj bloki catch, które są duże, pełne, pełne lub bardzo szczegółowe i trudne do rozbicia. Ponadto Java dodaje cały szum wokół zaznaczonych i niesprawdzonych wyjątków.

Jeśli zamiast tego twoja monada wyłapuje wyjątki i traktuje je jako właściwość przestrzeni monadycznej (zamiast jakiejś anomalii przetwarzania), możesz dowolnie mieszać i dopasowywać funkcje powiązane z tym obszarem, niezależnie od tego, co rzucą lub złapią.

Jeśli, jeszcze lepiej, twoja monada zapobiega warunkom, w których mogłyby się zdarzyć wyjątki (np. Wypchnięcie czeku zerowego do Może), to jeszcze lepiej. jeśli ... to jest dużo, dużo łatwiej wziąć pod uwagę i przetestować niż spróbować ... złapać.

Z tego, co widziałem, Go przyjmuje podobne podejście, określając, że każda funkcja zwraca (odpowiedź, błąd). To trochę tak samo, jak „podniesienie” funkcji do przestrzeni monady, w której typ odpowiedzi na rdzeń jest ozdobiony wskazaniem błędu i skutecznie rzuca na bok wyjątki.