Dlaczego w jednych językach spamowanie wyjątków jest akceptowalne, a w innych nie?

0

Moje (dotychczasowe) rozumienie wyjątku:

Sytuacja bezsensowna na tym poziomie zagłębienia kodu, z którą jednak jakaś metoda (istotnie) wyżej być może może sobie poradzić.

Czyli - przerzucamy kontrolę wyżej. Wyskakujemy nie z tej konkretnej funkcji, w której jesteśmy, ale idziemy w górę stosu tak wysoko, aż (być może) dojdziemy do funkcji, która powie: „z tym problemem mogę sobie poradzić”, czyli zawiera try. Jak takiej funkcji nie będzie, no to crash. Jest to wygodne, ponieważ dzięki temu nie musimy opatrywać ifami każdego wywołania być może problematycznej funkcji, jeśli z problemem i tak nie możemy zrobić nic, jak tylko przekazać go dalej.

if(!tryGetCośtam(out cośtam))
    return false;

doSomething(cośtam);
return true;

vs

var cośtam = getCośtam(); // w razie czego wyjątek pójdzie wyżej
doSomething(cośtam);
return;

W tym drugim przypadku nie musimy zaprzątać sobie głowy ew. problemami, które mogą wystąpić gdzieś niżej, a z ktorymi i tak nie moglibyśmy sobie poradzić.

Nie bez pewnego zdziwienia zauważyłem, że dla wielu to jest przykład TRAGICZNEGO programowania. Nazywają to: „antipattern of exception-driven developmnent”.

W zasadzie ich poglądy można podsumować prosto: Jeśli aplikacja może kontynuować, NIE NALEŻY rzucać wyjątków, gdyż jest to sytuacja „sensowna biznesowo”. Wyjątki służą do scrashowania aplikacji; w innym wypadku należy użyć innych mechanizmów.

Nie rozumiem skąd dokładnie to podejście; ale OK; należy uznać, że nie jestem najmądrzejszy, jeśli bardziej doświadczeni ode mnie tak uważają to pewnie mają powody. (Chociaż nie wszędzie widzę, jak można łatwo zamienić wyjątki z tego na try pattern.

JEDNAK - dziwi mnie, że to jest zależne od języka??

W C# na przykład chyba wyjątki są zakazane, trzeba używać "try pattern". „Vexxing exceptions”.

A w Pythonie jest na odwrót. Tam wyjątki są na kopy. Tam gdzie JA (który i tak spamuję za wiele wyjątków) bym dał sprawdzenie ifem, tam Pythonowcy robią try except.

Zdaje się, że w Pythonie przyjęło się podejście: Zakładaj, że wszystko się uda, jeśli się nie uda to chwyć wyjątek i zajmij się tym.

Czyli, jest dokładna odwrotnośc tego, co się promuje w C# czy Javie.

SKĄD TE RÓŻNICE?!?!?!

Widzę 2 możliwości:

  • To jest kwestia opinii i preferencji. Tak się przyjęło w C#/Javie, a w Pythonie inaczej; ale w zw. z tym nie ma (fundamentlalnych) przeszkód, by spamować wyjątkowami w Javie ani by ich unikać w Pythonie. I jakkolwiek unikanie WTF-ów ludzi przyzwyczajonych do podejścia przeciwnego może być istotnym argumentem, to jednak nie wystarczy to do uzasadnienia absolutyzmu obecnie promowanego twierdzenia, że „exception driven developmnet to antywzorzec”.
  • Istnieją fundamentalne różnice między obsługą wyjątków w Pythonie vs Java/C#. Te fundamentalne różnice sprawiają, że w Pythonie wyjątki mogą być stosowane do control flow, zaś w Javie/C# już nie. ALe jakie to są różnice? Nie wiem. Ani nie wiem, co sprawia, że w Javie/C# nie należy rzucać wyjątków, gdy nie trzeba robić crasha.

Która z tych możliwości jest prawdziwa? Jeśli ta druga, to o czym nie wiem/ czego nie rozumiem? Jeśli żadna, to jak jest naprawdę?

1

Zen Pythona /troche offtop a troche nie/

Beautiful is better than ugly.
Explicit is better than implicit.
Simple is better than complex.
Complex is better than complicated.
Flat is better than nested.
Sparse is better than dense.
Readability counts.
Special cases aren't special enough to break the rules.
Although practicality beats purity.
Errors should never pass silently.
Unless explicitly silenced.
In the face of ambiguity, refuse the temptation to guess.
There should be one-- and preferably only one --obvious way to do it.
Although that way may not be obvious at first unless you're Dutch.
Now is better than never.
Although never is often better than *right* now.
If the implementation is hard to explain, it's a bad idea.
If the implementation is easy to explain, it may be a good idea.
Namespaces are one honking great idea -- let's do more of those!
3

Zacznij pisać w C, nie będziesz miał problemów z wyjątkami.

0

Zgaduje, że bierze się to z tego, że w pythonie, a javie piszesz różne rzeczy. Jeśli kod w pythonie ma jakieś 50 linijek i gdzieś rzucisz wyjątkiem i od razu obok go ogarniasz, to łatwiej się połapiesz niż jak w jakimś większym czymś w javie. Gdy zaczniesz "spamować wyjątkami" na lewo i prawo to potem musisz szukać gdzie coś jest obsługiwany, gdzie nie i o co tu w ogóle chodzi.
Ewentualnie dostajesz takie super metody jak void validateX(X x) która rzuca wyjątkiem jeśli walidacja się nie powiedzie, w przeciwnym przypadku nic się nie dzieje.

2

Ile kosztuje wyjątek w C#/Javie, a ile w Pythonie?

Generalnie ja tam wolę stosować defensive programming wszędzie gdzie się da :P

1

Ja tam wale wyjatki gdzie sie da. Ostatni link dobrze to opisuje.

Przykladowo: nie znajde konfiguracji dla danego id wejsciowego.
Ja: wale wyjatek "nie mam konfiguracji dla kodu x"
Developer obok: w takiej sytuacji wystapi przeciez NullPointerException (linijke dalej albo i 300 linii dalej).

Termin "exception driven development" to dla mnie lenistwo intelektualne wynikajace prawdopodobnie z checi zamiecenia calego tematu w jeden kąt. A tak jak to opisano w ww artykule sa rozne rodzaje wyjatkow (takze w javie).

Wyjatkow w metodach typu Int.Parse nie lubie bo nawet jesli zrobisz na to wrapper to bedzie powolny. Do takich niskopoziomowych metod powinien byc odpowiednik z wynikiem w postaci kodu bledu.

3

Wszystko zależy od kontekstu, czy wyjątek dot. sytuacji biznesowej, aplikacyjnej czy może błędu w infrastrukturze, dot. to także miejsca w którym wyłapujesz ten wyjątek. Dla przykładu z "cośtam" możesz to robić dowolnie, kontekst jest najważniejszy, a Ty próbujesz dyskutować tylko o narzędziu. To trochę tak, gdyby na forum budowlańców ktoś się pytał o ciężar młotka (ilość używanych wyjątków), który ma zabierać do pracy i opisywałby rozmiar budynku (język programowania), a nie pracę którą ma wykonać w tym konkretnym dniu (kontekst).

Dużo zależy od programisty raczej a nie języka, chociaż nie mam dużego doświadczenia w Java/Python/C#, w świecie PHP używamy wyjątków - teraz wchodzę w świat Python więc spodziewaj się ich więcej skoro nie było ich za dużo ;)

0
kmph napisał(a):

Nie bez pewnego zdziwienia zauważyłem, że dla wielu to jest przykład TRAGICZNEGO programowania. Nazywają to: „antipattern of exception-driven developmnent”.

Czy masz na myśli to: https://softwareengineering.s[...]serious-antipattern-if-so-why ?

0
Silv napisał(a):
kmph napisał(a):

Nie bez pewnego zdziwienia zauważyłem, że dla wielu to jest przykład TRAGICZNEGO programowania. Nazywają to: „antipattern of exception-driven developmnent”.

Czy masz na myśli to: https://softwareengineering.s[...]serious-antipattern-if-so-why ?

Tego tekstu akurat nie czytałem, dzięki za linka.

Bardziej miałem na myśli m.in. to: jak rzucic wyjatek 404?

Jak już zalinkowałem to pinguję: @Koziołek , @jarekr000000

0
kmph napisał(a):

Bardziej miałem na myśli m.in. to: jak rzucic wyjatek 404?

W zasadzie nie rozumiem stanowiska @Koziołek z tego postu. Nie programuję w Javie, może dlatego. Wolałbym jednak, by w każdym języku przez "wyjątek" rozumiano to samo. Jeśli przez to pojęcie wyjątku będzie bardzo ogólne – niech będzie. Ale niech rozumie się to samo.

Dla mnie wyjątki są chyba czymś takim jak dla Ciebie, @kmph, i chyba jak dla @Markuz. Jest to próba niemieszania logiki jednej funkcji z logiką drugiej funkcji w przypadku sytuacji, które każą nam te "logiki" mieszać (czytaj: sytuacji błędnych w rozumieniu danej funkcji). Jeśli w kontekście jednej funkcji dana sytuacja jest błędna, to rzucamy wyjątek. Nie mówię o specyficznych mechanizmach konkretnych języków do obsługi "modelu sterowania wyjątkami".

W tym sensie wyjątki są dla mnie czymś przeciwnym do zwracanej wartości. Uważam, że jeśli funkcja zwraca wartość, to ma ona z definicji sens w jej logice.

1 użytkowników online, w tym zalogowanych: 0, gości: 1, botów: 0