Chyba w miarę upływu czasu zmieniają się oczekiwania użytkowników oraz mody wśród
autorów bibliotek.

Pytanie: jakie macie oczekiwania wobec bibliotek? Mają rzucać wyjątki?

Różne języki mają różne konwencje, ale nawet jeden język potrafi mieć różne polityki
w zależności od tego, jaki jest charakter wywoływanej funkcji.
Np. C++ rzuci wyjątkiem z operatora new, jeśli nie ma pamięci. Z tego powodu wyjątek
poleci też z każdej innej funkcji biblioteki std, ale nie każde niepowodzenie jest
tak zgłaszane. Np. błąd odczytu pliku albo błąd formatu danych w IOStreams już
wyjątkiem nie będzie.

Czy to jest zgodne z oczekiwaniami? Czy te oczekiwania zależą od rodzaju biblioteki?
Że np. akceptujemy wyjątek z biblioteki GUI, ale już z biblioteki I/O (jak IOStreams)
lepiej mieć status? A może jest inaczej?

Spotkałem się też z opinią, że biblioteka nie powinna rzucać wyjątków, bo w ten
sposób narzuca ten aspekt interfejsu aplikacji - ale już aplikacja końcowa może sobie
korzystać z wyjątków (które sama sobie zdefiniuje, sama rzuci i sama złapie), bo
nikomu innemu tego nie narzuca. Przyznam, że ten pogląd mnie zaintrygował
najbardziej, chociaż nie widzę możliwości jego konsekwentnego zastosowania wszędzie
(patrz choćby wspomniany operator new).
Są też języki, które używają wyjątków do zgłaszania wykroczeń poza ograniczenia
systemu typów (do tego zaliczam przekroczenia zdefiniowanych zakresów, wyjazd poza
tablicę, itp.). Nie widzę tego bez wyjątków. Ale powstaje też pytanie, na ile użycie
nieistniejącego indeksu w tablicy jest podobnym zjawiskiem do np. próby skorzystania
z nieistniejącego zasobu URL w sieci - i w jakim stopniu zgłaszanie takich błędów
powinno być podobne.
Itp., itd., etc.

Jak to widzicie obecnie? W C++? Gdzie indziej?

--
Maciej Sobczak * http://www.inspirel.com

do góry

2020-04-04 o 12:10 -0700, Maciej Sobczak napisał:
> Spotkałem się też z opinią, że biblioteka nie powinna rzucać
> wyjątków, bo w ten sposób narzuca ten aspekt interfejsu aplikacji -
> ale już aplikacja końcowa może sobie korzystać z wyjątków (które sama
> sobie zdefiniuje, sama rzuci i sama złapie), bo nikomu innemu tego
> nie narzuca.

Podzielam ten pogląd. Korzystając z biblioteki, oczekuję maksymalnie
uproszczonego działania, które nie zakłóci mi mojego workflow.
Łapanie wyjątków jest mi w tym kontekście wyjątkowo nie po drodze. Inna
sprawa, że w praktyce - jak zauważyłeś - jest jak jest.

Z tego samego powodu ubolewam nad funkcjami, które generują sygnały...
np. write() potrafi rzucić SIGPIPE, co narzuca na programiście by
uprzednio poustawiał sobie łapanie lub ignorowanie sygnałów. Co innego
oczywiście sygnały typu SIGSEGV, SIGQUIT czy SIGFPE - te występują w
przypadkach, w których tak czy inaczej sytuacja jest beznadziejna.

Mateusz

do góry

> > Spotkałem się też z opinią, że biblioteka nie powinna rzucać
> > wyjątków, bo w ten sposób narzuca ten aspekt interfejsu aplikacji -
> > ale już aplikacja końcowa może sobie korzystać z wyjątków (które sama
> > sobie zdefiniuje, sama rzuci i sama złapie), bo nikomu innemu tego
> > nie narzuca.
>
> Podzielam ten pogląd. Korzystając z biblioteki, oczekuję maksymalnie
> uproszczonego działania, które nie zakłóci mi mojego workflow.
> Łapanie wyjątków jest mi w tym kontekście wyjątkowo nie po drodze. Inna
> sprawa, że w praktyce - jak zauważyłeś - jest jak jest.

Ale zauważmy, że biblioteki też korzystają z bibliotek - i w ten sposób można
wytłumaczyć wyjątek out_of_memory: winę ponosi kto inny.

Weźmy np. bibliotekę do wysyłania maili. Powiedzmy, że zgodnie w powyższymi regułami
ona sama w sobie nie rzuca wyjątków, ale korzysta z innych bibliotek, w szczególności
z podstawowej biblioteki run-time, gdzie jest operator new. I tenże operator rzuca
wyjątek. Jeżeli biblioteka do maili jest poprawnie napisana, to będzie wewnętrznie
exception-safe, czyli przepuści wyjątki z niższych warstw (z operatora new),
pozostając sama w jakimś spójnym stanie. Przy takiej interpretacji można uznać, że
reguły są spełnione.

Jest jeszcze pomysł na funkcje callback, które są wołane w różnych awaryjnych
sytuacjach. Taki callback daje użytkownikowi możliwość np. logowania problemów wtedy
gdy występują, albo nawet rzucenia własnego wyjątku, właśnie po to, żeby go sobie
złapać gdzie indziej na poziomie tej samej aplikacji. Wtedy znowu mamy spełnione
reguły, że biblioteka sama z siebie nie rzuca wyjątków, ale je toleruje, jeśli jakieś
przez nią przelatują.

Na pewno nie jest łatwo takie biblioteki pisać, ale może to być jakiś ideał, którym
można się w miarę możliwości kierować.

--
Maciej Sobczak * http://www.inspirel.com

do góry