> > 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