Czy biblioteka powinna rzucać wyjątki?

[Maciej Sobczak]

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?

[Mateusz Viste]

Post by Maciej Sobczak
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

[Maciej Sobczak]

Post by Mateusz Viste

Post by Maciej Sobczak
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ć.