https://dzone.com/articles/how-to-properly-use-exceptions-in-java
Zgadzacie sie z tym artykulem czy wrecz przeciwnie?
0
0
Zgadzam się z tym że nie należy bawić się w kontrolowanie przepływu programu za pomocą wyjątków. Jak rzucasz i łapiesz w tej samej metodzie to coś jest nie tak.
Ale z resztą sie nie zgadzam, bo takie podejście działa tylko jak klepiesz ten projekt SAM i jest on względnie mały. Prawda jest taka że prawdziwy kod ewoluuje i bardzo łatwo zgubić jakiś exception handler jeśli wyjątek jest runtime i go "nie widać". To może skutkować nieoczekiwanym położeniem produkcyjnej aplikacji z jakiegoś głupiego powodu.
RuntimeException to można rzucić jak coś się tak całkiem mega rypnęło i chcemy zachować w logu informacje o tym co poszło nie tak. Checked exceptions są na sytuacje "wyjątkowe" ale takie z których możemy sie jeszcze jakoś uratować kilka poziomów wyżej.
Na przykład jak odpalamy jakiś serwis bazujący na pliku konfiguracyjnym i gdzieś w konfiguracji jest błąd i serwis sie sypnie to oczekiwałbym jednak że to będzie checked exception bo co prawda jest to sytuacja niezbyt normalna, ale jednocześnie możemy w prezenterze to złapać i wysłać info do użytkownika żeby poprawił konfiguracje.
0
Jestem podobnego zdania. W sumie to z jakich dokladnie powodow np. Scala zrezygnowala z checked exceptions?
0
Ze scalą jest podobny "problem" jak z używaniem wyjątków w lambdach które chcesz aplikować na strumieniach w Java 8. map czy collect nie rzucają wyjątków więc nie może go też rzucać aplikowana lambda / metoda. Z drugiej strony gdyby te metody rzucały wyjątki to musiałbyś zawsze osbługiwać wyjątki, nawet takie "widmo", które na przykład w ogóle nie występują. Jak widać zarówno jedno jak i drugie rozwiązanie jest dziwne. Niemniej rozwiązanie bez wyjątków jest bardziej "uniweralne" bo zawsze mozesz rzucić runtime exception.
Dodatkowo scala może zwracać takie coś jak Either[] gdzie mozesz zadeklarować ze metoda zwraca wynik lub wyjątek.