🚀 go-pugleaf

Grzesiek G. napisał(a):
> Ale zadanie wykonywane przez program to jest coś, co jest opisane w 
> jakimś dokumencie. Więc jeżeli nikt nie napisał, że sprawdzanie 
> istnienia pliku jest częścią zadania, to (według przedstawionej przeze 
> mnie teorii) jest sytuacją wyjątkową i można ją śmiało obsłużyć przez 
> catch.
> 
> Co do tezy, że klient nie interesuje się tym co robi w środku metoda się 
> zgadzam. Jednak klienta interesuje jak robi. Więc jeśli robi zbyt wolno, 
> bo przebieg programu jest sterowany wyjątkami, to klient może się 
> zainteresować.

Przedstawiona teoria jest dla mnie bardzo naciągana, z tego powodu, że 
klient, jeśli mu zależy na wydajności, to napisze o tym wprost, i to w 
odniesieniu do konkretnych przypadków użycia, a nie w postaci stwierdzeń 
na temat obsługi wyjątków w ciałach poszczególnych metod.
Wyjątki mogą stanowić problem wydajnościowy w marginalnych wypadkach i 
tylko raport narzędzia typu profiler może stanowić przesłankę do 
zastąpienia ich czymś innym. Byłbym bardzo zainteresowany usłyszeniem o 
przypadku, w którym u kogoś to faktycznie obsługa wyjątków pod względem 
wydajności stanowiła wąskie gardło systemu, przez co system nie spełniał 
wymagań wydajnościowych postawionych mu przez klienta.
Jeszcze raz za mistrzem Knuthem powtórzę, że "premature optimization is 
the root of all evil"

> Takiego klienta, który to specyfikuje, też nie spotkałem, ale mam często 
> taki przypadek: klient chce żeby aplikacja importowała dane z pliku do 
> własnego serwera bazy danych. Import może się nie powieść z powodu 
> błędnej zawartości pliku. Błąd jest sygnalizowany przez serwer bazy 
> danych w sposób nieczytelny dla zwykłego użytkownika. Jeżeli użytkownik 
> chce widzieć błąd w sposób czytelny (bo np. plik jest tworzony ręcznie) 
> to i tak trzeba dorzucić ręczną walidację opartą na ifach.

Jasne, bywa, że wyjątek wyrzucany przez sterownik JDBC, czy jakąkolwiek 
inną bibliotekę nie niesie ze sobą informacji istotnych z punktu 
widzenia użytkownika (choć bywa tak rzadko, bo przeważnie można taki 
wyjątek przechwycić, opakować w swój własny uzupełniający informację i 
obsłużyć go we właściwym miejscu programu). Czasem jednak tak bywa i 
walidację trzeba przeprowadzić wcześniej, gdy informacje interesujące 
użytkownika (np. zawartość pliku) są jeszcze dostępne. Jest to właśnie 
domena instrukcji typu "if" i nie zamierzam kwestionować ich 
użyteczności w tych zastosowaniach. Niemniej jednak uważam, że 
zastosowanie wyjątków jest lepsze, jeśli tylko w danym przypadku jest 
możliwe.

> Ale co w sytuacji, gdy 
> wszystkie błędy wywoływania zapytań bazy danych zwracają wyjątek 
> SqlException?

Zmienić bibliotekę? :-) Akurat do zapewniania obiektom trwałości w Javie 
jest spory wybór, jeśli chodzi o biblioteki.
Można też kusić się o pisanie własnych klas opakowujących wywołania kodu 
bibliotek, wprowadzanie foreign methods, istnieje wiele różnych technik.

--
Pozdrawiam,
Przemysław Pokrywka