Inne podejście do obsługi błędów w Java - na wzór m.in. Scala czy Rust

Question

Dosć ciekawy artykuł:

https://medium.com/@alexeynovikov_89393/stop-using-exceptions-in-java-456f7db46ea4

 

public class Result<T> {
  private Optional<T> value;
  private Optional<String> error;

  private Result(T value, String error) {
    this.value = Optional.ofNullable(value);
    this.error = Optional.ofNullable(error);
  }

  public static <U> Result<U> ok(U value) {
    return new Result<>(value, null);
  }

  public static <U> Result<U> error(String error) {
    return new Result<>(null, error);
  }

  public boolean isError() {
    return error.isPresent();
  }

  public T getValue() {
    return value.get();
  }

  public String getError() {
    return error.get();
  }
}

Answer 1

Szkoda, że nie pokazał przykładu użycia. Od wyjątków w Javie nie da się uciec. Tak czy siak wszystkie funkcje używające używające bibliotek będą musiały używać bloków try {} catch {}.
Dodatkowo kod stanie się mniej czytelny, bo co wywołanie funkcji trzeba będzie ręcznie sprawdzać czy nie zwróciła błędu.
Zamiast funkcji w stylu

PROPERTY downloadSomeClassProperty(String key) {
    URL url = generateURL();
    DATA data = fetchData(url);
    SOME_CLASS someClass = parseData(data);
    return someClass.getProperty(key);
}

public void someUIAction() {
   try {
       // .... jakiś kod
       PROPERTY someProperty = downloadSomeClassProperty(someKey);
       // .... jakiś kod
   }
   catch (Exception e) {
      // show error
   }
}

Trzeba będzie napisać

Result<PROPERTY> downloadSomeClassProperty(String key) {
    Result<URL> url = generateURL();
    if (url.isError())
        return new Result<PROPERTY>(url.getError());
    Result<DATA> data = fetchData(url);
    if (data.isError())
        return new Result<PROPERTY>(data.getError());
    SOME_CLASS someClass = parseData(data);
    if (someClass.isError())
        return new Result<PROPERTY>(someClass.getError());
    return someClass.getProperty(key);
}

public void someUIAction() {
   // .... jakiś kod
   PROPERTY someProperty = downloadSomeClassProperty(someKey);
   if (someProperty.isError()) {
         // show error
         return;
   }
   // .... jakiś kod
}

 

Comments

Tu, jego kolega, szczegółowo opisał sposób użycia:

https://medium.com/@afcastano/monads-for-java-developers-part-2-the-result-and-log-monads-a9ecc0f231bb

Uniknęli try/catch, są użyte tylko if. Czyli tak jak u Ciebie.

---

Bloków try/catch nie da się uniknąć używając funkcji z biblioteki standardowej. Jeżeli będą wykonywać jakiekolwiek I/O będą musieli je owrapować blokiem try/catch. Potem będą mogli wyżej w kodzie używać swojego stylu.

Ale powiedz mi tak szczerze, który kod według ciebie jest bardziej czytelny?

---

Tak nic chłopaki nie wymyślą, musieli by grzebać w kodzie JDK i zrobić alternatywną wersje Javy.

Który kod jest czytelniejszy? No jak ktoś naśladuje Rusta, to wiadomo który :) Ale też w dużym stopniu decyduje o tym przyzwyczajenie, który kod wpisywałeś już setki czy tysiące razy.

---

To w sumie taki powrót do starego stylu sprawdzania błędów co operacja. Ktoś po coś wymyślił te exception. Przecież funkcje systemowe ich nie generują, w takie np. bibliotece javy sprawdzany jest kod błędu (errno) i stosownie do tego generowany (lub nie) wyjątek. I teraz trzeba wykonać operację odwrotną...

Exceptions mają dwie ważne zalety:

Oddzielenie kodu "biznesowego" od obsługi błędów - co pokazał #tangarr.

Możliwość prostego przeniesienia obsługi błedów wyżej - w większości przypadków im wyżej w logice kodu tym bardziej konkretnie można obsłużyć błąd - np. gdzieś w kodze "wykonawczym" nie daje się otworzyć pliku, ale w GUI można poinformować usera i zapytać się co zrobić. Dobra zasada jest taka że błąd ignorujemy, aż dotrze na poziom, gdzie wiadomo co z nim zrobić. Gdy nie wiadomo -  spowoduje koniec programu z komunikatem - lepsze niż błędne wyniki.

---

@tangarr, nie trzeba try/catcha można samo try with Resources dla IO :) w javie wszyskite nowe operacje I/O musza implementowac interfejs AutoCloseable, z tej racji zabezpieczyc mozna spokojnie blok Try/Resources redukujac ilosc operacji jak równiez redukujac ilosc potencjanych odwolan do wywolania bledów. 


Dodatkowo da się uciec od exceptionali, gdyż można je zignorować z wykorzystaniem funkcyjnych interfejsów, po prostu przekazać je jako wywołanie  w innym wątku.  To nie jest dobre, ale "da się", tzn. da się ostatecznie uciec od wyjątków, też dlatego powstały strumienie funkcyjne żeby to ograniczać i umiejętnie  wykorzystywać  przekierowania 

Zgodzę się, że bypass nigdy nie wystąpi w Javie i taka jej natura, ale można dużo poradzić supress/ignore java Niejawnie jest wstanie ignorować wystąpienie błędu nawet bez wykorzystania adnotacji do tego.

Przypominam, że finally zawsze się wykona niezależnie od tego jaki wyjątek został wyrzucony, a w tym też można fajnie i sporo podziałac.