🚀 go-pugleaf

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