🚀 go-pugleaf

Użytkownik "Przemek Pokrywka" <adres@zastrzezony.com> napisał w wiadomości
news:e09c3r$lg3$1@news.onet.pl...
> [...]
> Jak Państwa zdaniem powinna wyglądać optymalna obsługa sytuacji
> wyjątkowej przez tą metodę, gdyby pisać ten system na nowo?
> - Czy najlepiej zwracać by wartość null, jak w tej chwili?
> - Czy wyrzucać wyjątek?
> - Zakładając, że system pisany byłby w Javie, jakiego typu wyjątek -
> checked, czy unchecked?
>
> Z pewnych względów wolałbym nie stosować tu wzorca Null Object (Woolf).
>

Jezeli wyszukiwana osoba ma prawo nie figurowac w spisie (np. szukam
znajomego w ksiazce telefonicznej, ale nie wiem, czy ma telefon, czy nie) to
nieznalezienie jej nie jest sytuacja wyjatkowa. Nalezy wowczas zwrocic NULL.
Jezeli natomiast wiem, ze osoba powinna byc w spisie, a okaze sie, ze jej
nie ma to jest wyjatek i trzeba rzucic checked exception.

Adam

Adam Przybyłek napisał(a):
> Jezeli wyszukiwana osoba ma prawo nie figurowac w spisie (np. szukam
> znajomego w ksiazce telefonicznej, ale nie wiem, czy ma telefon, czy nie) to
> nieznalezienie jej nie jest sytuacja wyjatkowa. Nalezy wowczas zwrocic NULL.

No dobrze, załóżmy więc, że sytuacja nie jest wyjątkowa - zwrócę NULL. 
Co ma zrobić w tej sytuacji kod wywołujący metodę find?
Jednym z wyjść (bardzo popularnym) jest optymistyczne założenie, że 
udało się znaleźć znajomego. Teraz w lepszym przypadku kod usiłuje 
następnie wywołać na nim metodę getAge, co prowadzi do łatwego do 
znalezienia błędu.
W gorszym przypadku, kod zapamiętuje tego (jak sądzi) "znajomego" w 
pewnej kolekcji. Po dłuższym czasie działania programu po kolekcji tej 
iteruje inny wątek, wywołując metodę getAge na każdym elemencie. Nagle 
okazuje się, że wystąpił błąd. Gdzie leży jego przyczyna, gdy kolekcja 
jest aktualizowana z bardzo wielu miejsc programu?

Odporny na błędy kod sprawdzi oczywiście, czy wartość zwrócona przez 
find nie jest aby NULLem. Czy jednak kod upstrzony wieloma warunkami if 
jest bardziej czytelny i lepiej wyraża intencję autora od kodu 
zawierającego klauzule obsługi wyjątków? Czy enigmatyczny "NULL" lepiej 
komunikuje fakt nieodnalezienia obiektu od wyjątku o nazwie 
PersonNotFoundException? Nie sądzę, i dlatego uważam, że teza postaci:

"ma prawo nie zostać odnaleziona" => "nieodnalezienie jej nie jest 
sytuacją wyjątkową" => "nie należy zgłaszać wyjątku"

nie jest prawdziwa (ze względu na drugą implikację).

Zapraszam jednak do dzielenia się innymi argumentami, gdyby ktoś doszedł 
do innych wniosków.

Przemysław Pokrywka

Przemek Pokrywka <adres@zastrzezony.com> writes:

> No dobrze, załóżmy więc, że sytuacja nie jest wyjątkowa - zwrócę NULL.
> Co ma zrobić w tej sytuacji kod wywołujący metodę find?

Nie da się odpowiedzieć na tak ogólne pytanie. Zależy, jakie
zachowanie jest po nim oczekiwane.

> Odporny na błędy kod sprawdzi oczywiście, czy wartość zwrócona przez
> find nie jest aby NULLem. Czy jednak kod upstrzony wieloma warunkami
> if jest bardziej czytelny i lepiej wyraża intencję autora od kodu
> zawierającego klauzule obsługi wyjątków?

Jeśli sytuacja, kiedy elementu nie ma w spisie, jest normalna, to tak.
Jeśli jest wyjątkowa i w takim przypadku należy przerwać dalsze
obliczenia dużej części programu, to nie. (Dobry interfejs spisu
udostępnia takie i takie wyszukiwanie.)

-- 
   __("<         Marcin Kowalczyk
   \__/       qrczak@knm.org.pl
    ^^     http://qrnik.knm.org.pl/~qrczak/

Użytkownik "Przemek Pokrywka" <adres@zastrzezony.com> napisał w wiadomości 
news:e09gjn$737$1@news.onet.pl...

> uważam, że teza postaci:
>
> "ma prawo nie zostać odnaleziona" => "nieodnalezienie jej nie jest 
> sytuacją wyjątkową" => "nie należy zgłaszać wyjątku"
>
> nie jest prawdziwa (ze względu na drugą implikację).
>
> Zapraszam jednak do dzielenia się innymi argumentami, gdyby ktoś doszedł 
> do innych wniosków.


Witam. Pozwolę sobie zaprezentować zdanie odmienne. Moje argumenty:

1. Już samo określenie wyjątek sugeruje, że chodzi o sytuację rzadko 
spotykaną. Nieznalezienie obiektu jest w opisanym przypadku równie 
uprawnione jak jego znalezienie. Sytuacja daje się łatwo obsłużyć w językach 
bez obsługi wyjątków. (To argument dość subiektywny, więc nie 
najmocniejszy.)

2. Czytelność kodu. Uważam, że linia postaci:

if (person == null) // nie znaleziono osoby

jest bardziej czytelna niż blok chwytania wyjątku.

3. Efektywność. Porównanie z nullem to fizycznie banalne sprawdzenie. 
Rzucanie i chwytanie wyjątku jest kosztowne. Nie wytaczajmy armaty na 
wróble.

Posłużenie się wyjątkiem miałoby wg mnie sens w następującej sytuacji:

W przebiegu może zajść więcej negatywnych zdarzeń, np. brak uprawnień do 
danych osoby, dane osoby uniemozliwiają przeprowadzenie dalszych obliczeń 
(np. obliczenie dni urlopu dla emeryta) itp. W takiej sytuacji można 
załatwić wszystkie możliwe wyjątki jednym blokiem przechwytywania, pod 
warunkiem, że ich sposób obsłużenia będzie identyczny niezależnie od typu 
wyjątku, np. opis wyjątku jest czytelny dla użytkownika i wystarczy 
wyświetlić go w oknie komunikatu.

Pozdrawiam

x-plorer 

Dziękuję za ciekawą wypowiedź, choć zgadzam się z nią w (mniej więcej) 
połowie

x-plorer napisał(a):
> 1. Już samo określenie wyjątek sugeruje, że chodzi o sytuację rzadko 
> spotykaną. Nieznalezienie obiektu jest w opisanym przypadku równie 
> uprawnione jak jego znalezienie.

Najpierw spróbuję pokazać, że branie określenia "wyjątek" dosłownie może 
nieść za sobą niebezpieczeństwo zignorowania jego istoty jako 
konstrukcji programistycznej.

Choć wprawdzie te dwie sytuacje są równouprawnione, to bywa, że język 
traktuje je nierówno. Przy okazji może wyjść tu moje skażenie Javą i 
przyzwyczajeniem do wyjątków sprawdzanych przez kompilator (AFIK rzadko 
występujących w popularnych językach programowania).
Otóż w wypadku nieodnalezienia obiektu, gdy
a) zwrócony jest null, nic nie powstrzyma roztargnionego programisty 
przed zignorowaniem takiej sytuacji, co najprawdopodobniej zakończy się 
błędem w znacznie dalszej części programu, gdzie znalezienie go nie 
będzie już takie oczywiste.
b) wyrzucony jest wyjątek sprawdzany przez kompilator, błąd kompilacji 
uniemożliwi roztargnionemu programiście przejście dalej

W przypadku wyrzucenia wyjątku programista jest więc wspierany przez 
kompilator w prawidłowej obsłudze wszystkich przypadków.
Owszem, zdarzają się ludzie, którzy po błędzie kompilacji szybko 
dopisują pustą klauzulę catch, ale nie mam takich na myśli.

Następnie chciałbym wykazać, że równouprawnienie dwóch sytuacji nie jest 
wystarczającą przesłanką, żeby nie używać wyjątków.
W aplikacjach, które często operują na plikach na każdym kroku może 
wystąpić sytuacja błędu odczytu/zapisu/nieodnalezienia pliku. Pomimo, że 
zarówno sytuacja odnalezienia pliku, jak i ta przeciwna są 
równouprawnione, zakłada się jednak jakiś podstawowy scenariusz 
działania aplikacji, w którym dobrze wykona ona zadania, do których jest 
przeznaczona. Prawdziwe równouprawnienie przypadków niemal nie występuje 
w praktyce. Przy takich założeniach kod, który w głównym "nurcie" 
rozpatruje te pozytywne przypadki, a w klauzulach obsługi wyjątków 
zajmuje się tymi negatywnymi jest moim zdaniem bardziej czytelny, niż 
kod, który w równouprawnionych gałęziach instrukcji warunkowej 
rozpatruje przypadek podstawowy i alternatywny.
Innymi słowy, użycie instrukcji warunkowej do odróżnienia przypadków 
podstawowego i alternatywnego jest dla mnie "zbyt łaskawym" 
potraktowaniem przypadku alternatywnego.
O prawdziwym równouprawnieniu dwóch przypadków możnaby mówić moim 
zdaniem np. w określaniu płci osoby (i to tylko w aplikacjach, których 
zasadnicze działanie jest niezależnie od tego atrybutu osoby).

> 2. Czytelność kodu. Uważam, że linia postaci:
> 
> if (person == null) // nie znaleziono osoby
> 
> jest bardziej czytelna niż blok chwytania wyjątku.

twierdzę, że od

Person person = find("nemo");
if (person != null)
	process(person);
else
	noPersonFoundCase();

czytelniejsze jest:
try {
	Person person = find("nemo");
	process(person);
catch (PersonNotFoundException e) {
	noPersonFoundCase();
}

dlatego, że w drugim przypadku można w sposób niezakłócony prześledzić 
proces wyszukiwania i przetwarzania obiektu Person z jasno oddzieloną 
obsługą sytuacji wyjątkowej.

> 3. Efektywność. Porównanie z nullem to fizycznie banalne sprawdzenie. 
> Rzucanie i chwytanie wyjątku jest kosztowne. Nie wytaczajmy armaty na 
> wróble.

"Premature optimization is the root of all evil" jak powiedział mistrz 
Knuth - jak zawsze, diabeł tkwi w szczegółach. Rezygnacja z lepszej 
konstrukcji językowej na rzecz niejasnych korzyści wydajnościowych nie 
jest moim zdaniem dobrą praktyką. Jeśli profiling aplikacji wykaże, że 
obsługa wyjątków jest wąskim gardłem, to zgodziłbym się, że w danej 
sytuacji użycie wyjątków może nie być najlepszym wyjściem. Idę jednak o 
zakład, że wyjątki nie stanowią wąskiego gardła w 80% aplikacji.

> Posłużenie się wyjątkiem miałoby wg mnie sens w następującej sytuacji:
> 
> W przebiegu może zajść więcej negatywnych zdarzeń, np. brak uprawnień do 
> danych osoby, dane osoby uniemozliwiają przeprowadzenie dalszych obliczeń 
> (np. obliczenie dni urlopu dla emeryta) itp. W takiej sytuacji można 
> załatwić wszystkie możliwe wyjątki jednym blokiem przechwytywania, pod 
> warunkiem, że ich sposób obsłużenia będzie identyczny niezależnie od typu 
> wyjątku, np. opis wyjątku jest czytelny dla użytkownika i wystarczy 
> wyświetlić go w oknie komunikatu.

Zgadzam się z takim wnioskiem - jednak opisana sytuacja to dla mnie nie 
jest jedyna, w której widziałbym uzasadnienie dla użycia wyjątków.

--
Pozdrawiam,
Przemysław Pokrywka

Marcin 'Qrczak' Kowalczyk napisał(a):
> Przemek Pokrywka <adres@zastrzezony.com> writes:
> 
> 
>>No dobrze, załóżmy więc, że sytuacja nie jest wyjątkowa - zwrócę NULL.
>>Co ma zrobić w tej sytuacji kod wywołujący metodę find?
> 
> 
> Nie da się odpowiedzieć na tak ogólne pytanie. Zależy, jakie
> zachowanie jest po nim oczekiwane.

Najprościej ujmując, oczekiwane jest prawidłowe obsłużenie obydwu 
sytuacji. Najczęściej (choć nie zawsze) oznaczać to będzie występowanie 
jakiegoś rodzaju identyfikacji (if, try/catch, ...) danego przypadku w 
okolicach wywołania metody find.

>>Odporny na błędy kod sprawdzi oczywiście, czy wartość zwrócona przez
>>find nie jest aby NULLem. Czy jednak kod upstrzony wieloma warunkami
>>if jest bardziej czytelny i lepiej wyraża intencję autora od kodu
>>zawierającego klauzule obsługi wyjątków?
> 
> 
> Jeśli sytuacja, kiedy elementu nie ma w spisie, jest normalna, to tak.
> Jeśli jest wyjątkowa i w takim przypadku należy przerwać dalsze
> obliczenia dużej części programu, to nie. (Dobry interfejs spisu
> udostępnia takie i takie wyszukiwanie.)
> 

W zasadzie zgodzę się ze wszystkimi Pana wnioskami. Sęk jednak w tym, że 
niemal nie spotyka się sytuacji w 100% równouprawnionych. Oczywiście, 
jednak czasem takie się zdarzają i dlatego uważam za słuszną uwagę o 
dobrym interfejsie spisu.

--
Pozdrawiam,
Przemysław Pokrywka

Użytkownik "Przemek Pokrywka" <adres@zastrzezony.com> napisał w wiadomości
news:e0c8eh$ur8$1@news.onet.pl...
>
> [...]
> W aplikacjach, które często operują na plikach na każdym kroku może
> wystąpić sytuacja błędu odczytu/zapisu/nieodnalezienia pliku. Pomimo, że
> zarówno sytuacja odnalezienia pliku, jak i ta przeciwna są
> równouprawnione, zakłada się jednak jakiś podstawowy scenariusz
> działania aplikacji, w którym dobrze wykona ona zadania, do których jest
> przeznaczona.

Blad odczytu/zapisu to wlasnie sytuacja nietypowa. Normalnie zapisujac plik
na dysku oczekujesz, ze zapis sie uda. Co innego odnalezienie pliku.
Wyswietlasz okienko zeby uzytkownik wpisal plik, ktory chce otworzyc. Jezeli
plik taki nie istnieje to nie jest zaden wyjatek i prosisz uzytkownika, aby
wprowadzil inna nazwe pliku. Jesli natomiast plik podany przez uzytkownika
istnieje, ale z jakichs wzgledow nie moze byc odczytany, np. bad sector to
wtedy jest sytuacja wyjatkowa i rzucany jest wyjatek.

Adam

Adam Przybyłek napisał(a):
> Blad odczytu/zapisu to wlasnie sytuacja nietypowa. Normalnie zapisujac plik
> na dysku oczekujesz, ze zapis sie uda.

Tak, w zupełności.

> Co innego odnalezienie pliku.

Doprawdy?

> Wyswietlasz okienko zeby uzytkownik wpisal plik, ktory chce otworzyc. Jezeli
> plik taki nie istnieje to nie jest zaden wyjatek i prosisz uzytkownika, aby
> wprowadzil inna nazwe pliku. 

A co, jeśli nie wyjątek? Użytkownik nie wpisuje nazwy pliku, o którym 
wie, że nie istnieje. Jeśli ten plik wbrew jego przekonaniom nie 
istnieje, lub on sam się pomylił, to jest to dla niego sytuacja 
niespodziewana i nie można jej uznać za sytuację "normalną".

Sens wyboru właściwej opcji (wyjątek/instrukcja warunkowa) da się 
zrozumieć przechodząc do kodu, który w wypadku użycia wyjątków czyta się 
znacznie naturalniej i który w bardziej przejrzysty sposób uwidacznia 
swoje intencje.

> Jesli natomiast plik podany przez uzytkownika
> istnieje, ale z jakichs wzgledow nie moze byc odczytany, np. bad sector to
> wtedy jest sytuacja wyjatkowa i rzucany jest wyjatek.

Po lekturze tego zdania odnoszę wrażenie, że zakładasz istnienie 
jakiegoś pojedynczego, zunifikowanego sposobu obsługi wyjątków: "rzucany 
jest wyjątek" nasuwa mi skojarzenia z jakimś okienkiem dialogowym z 
napisem "Unhandled exception", nic nie mówiącym numerem i przyciskiem 
"ok", albo z niebieskim ekranem ;) - na ile się orientuję, jest to 
popularny sposób obsługi błędów w aplikacjach C# będących w trakcie rozwoju.
Jeśli tak, to nic bardziej błędnego - ja zakładam, że wszystkie wyjątki 
są pod ścisłą kontrolą aplikacji, która może w przypadku ich wystąpienia 
np. poprosić użytkownika o inną nazwę pliku, ukrywając przed nim fakt 
wystąpienia jakiegokolwiek wyjątku.

--
Przemysław Pokrywka

Użytkownik "Przemek Pokrywka" <adres@zastrzezony.com> napisał w wiadomości
news:e0ced6$f7g$1@news.onet.pl...
> Adam Przybyłek napisał(a):
> > Blad odczytu/zapisu to wlasnie sytuacja nietypowa. Normalnie zapisujac
plik
> > na dysku oczekujesz, ze zapis sie uda.
>
> Tak, w zupełności.
>
> > Co innego odnalezienie pliku.
>
> Doprawdy?
>
> > Wyswietlasz okienko zeby uzytkownik wpisal plik, ktory chce otworzyc.
Jezeli
> > plik taki nie istnieje to nie jest zaden wyjatek i prosisz uzytkownika,
aby
> > wprowadzil inna nazwe pliku.
>
> A co, jeśli nie wyjątek? Użytkownik nie wpisuje nazwy pliku, o którym
> wie, że nie istnieje. Jeśli ten plik wbrew jego przekonaniom nie
> istnieje, lub on sam się pomylił, to jest to dla niego sytuacja
> niespodziewana i nie można jej uznać za sytuację "normalną".
>

Po wprowadzeniu przez uzytkownika nazwy pliku robisz:
File myFile = new File("nazwaPliku");
if (myFile.exists() ){ ... }

Adam

"Adam Przybyłek" <adampap@panda.bg.univ.gda.pl> writes:

> Po wprowadzeniu przez uzytkownika nazwy pliku robisz:
> File myFile = new File("nazwaPliku");
> if (myFile.exists() ){ ... }

A jeśli w momencie sprawdzania jeszcze istnieje, ale w momencie
otwierania już nie?

-- 
   __("<         Marcin Kowalczyk
   \__/       qrczak@knm.org.pl
    ^^     http://qrnik.knm.org.pl/~qrczak/

Użytkownik "Marcin 'Qrczak' Kowalczyk" <qrczak@knm.org.pl> napisał w
wiadomości news:87y7ytka81.fsf@qrnik.zagroda...
> "Adam Przybyłek" <adampap@panda.bg.univ.gda.pl> writes:
>
> > Po wprowadzeniu przez uzytkownika nazwy pliku robisz:
> > File myFile = new File("nazwaPliku");
> > if (myFile.exists() ){ ... }
>
> A jeśli w momencie sprawdzania jeszcze istnieje, ale w momencie
> otwierania już nie?
>

No to wtedy juz jest sytuacja nieoczekiwana i na ta okolicznosc przewidziany
jest wyjatek.

Adam

"Adam Przybyłek" <adampap@panda.bg.univ.gda.pl> wrote:

> > > Po wprowadzeniu przez uzytkownika nazwy pliku robisz:
> > > File myFile = new File("nazwaPliku");
> > > if (myFile.exists() ){ ... }
> >
> > A jeśli w momencie sprawdzania jeszcze istnieje, ale w momencie
> > otwierania już nie?
> >
>
> No to wtedy juz jest sytuacja nieoczekiwana i na ta okolicznosc
> przewidziany jest wyjatek.

Zupelnie bez sensu. Ten pierwszy test wtedy czegokolwiek nie daje.


mp

Użytkownik "Michal Przybylek" <mrp@neostrada.pl> napisał w wiadomości
news:e0ef6i$h84$1@nemesis.news.tpi.pl...
> "Adam Przybyłek" <adampap@panda.bg.univ.gda.pl> wrote:
>
> > > > Po wprowadzeniu przez uzytkownika nazwy pliku robisz:
> > > > File myFile = new File("nazwaPliku");
> > > > if (myFile.exists() ){ ... }
> > >
> > > A jeśli w momencie sprawdzania jeszcze istnieje, ale w momencie
> > > otwierania już nie?
> > >
> >
> > No to wtedy juz jest sytuacja nieoczekiwana i na ta okolicznosc
> > przewidziany jest wyjatek.
>
> Zupelnie bez sensu. Ten pierwszy test wtedy czegokolwiek nie daje.
>

Ale elegancko wyglada. Bo na pierwszym lapiesz sytuacje typu ktos zrobil
literowke podajac nazwe pliku.
A sytuacja, ze pierwszy test zakonczy sie powodzeniem, a potem w ulamku
sekundy ktos skasuje plik zanim zdarzysz go otworzyc jest wyjatkowa i na ta
okazje przygotowano wyjatki.

Adam

Adam Przybyłek napisał(a):
> Użytkownik "Michal Przybylek" <mrp@neostrada.pl> napisał w wiadomości
> news:e0ef6i$h84$1@nemesis.news.tpi.pl...
> 
>>"Adam Przybyłek" <adampap@panda.bg.univ.gda.pl> wrote:
>>
>>
>>>>>Po wprowadzeniu przez uzytkownika nazwy pliku robisz:
>>>>>File myFile = new File("nazwaPliku");
>>>>>if (myFile.exists() ){ ... }
>>>>
>>>>A jeśli w momencie sprawdzania jeszcze istnieje, ale w momencie
>>>>otwierania już nie?
>>>>
>>>
>>>No to wtedy juz jest sytuacja nieoczekiwana i na ta okolicznosc
>>>przewidziany jest wyjatek.
>>
>>Zupelnie bez sensu. Ten pierwszy test wtedy czegokolwiek nie daje.
>>
> 
> 
> Ale elegancko wyglada. Bo na pierwszym lapiesz sytuacje typu ktos zrobil
> literowke podajac nazwe pliku.
> A sytuacja, ze pierwszy test zakonczy sie powodzeniem, a potem w ulamku
> sekundy ktos skasuje plik zanim zdarzysz go otworzyc jest wyjatkowa i na ta
> okazje przygotowano wyjatki.

I bez sensu, i nieelegancko. Próba odczytu pliku sprawdza też jego 
istnienie, więc test w instrukcji warunkowej jest zduplikowany (a na 
dodatek zbędny). Sprawdzenie zaciemnia tylko obraz pozytywnego 
scenariusza działania aplikacji.
Nie wiem, czemu ma ono służyć - zademonstrowaniu innym programistom 
czytającym kod, że owszem, przewiduje się sytuację pomyłki użytkownika? 
Bo żadnych korzyści z punktu widzenia poprawnego działania aplikacji nie ma.

--
Przemysław Pokrywka

Użytkownik "Przemek Pokrywka" <adres@zastrzezony.com> napisał w wiadomości
news:e0ejpu$27n$1@news.onet.pl...

>
> I bez sensu, i nieelegancko. Próba odczytu pliku sprawdza też jego
> istnienie, więc test w instrukcji warunkowej jest zduplikowany (a na
> dodatek zbędny). Sprawdzenie zaciemnia tylko obraz pozytywnego
> scenariusza działania aplikacji.
> Nie wiem, czemu ma ono służyć - zademonstrowaniu innym programistom
> czytającym kod, że owszem, przewiduje się sytuację pomyłki użytkownika?
> Bo żadnych korzyści z punktu widzenia poprawnego działania aplikacji nie
ma.
>

Nieelegancko, bo chcesz sprowadzic "try" do poziomu instrukcji sterujacych
"if", "for", "while".

Adam

Adam Przybyłek napisał(a):
> Nieelegancko, bo chcesz sprowadzic "try" do poziomu instrukcji sterujacych
> "if", "for", "while".

A czy w ten sposób ujmę mu czegokolwiek? :)
W trakcie programowania z uwagą wsłuchuję się w mój kod i słyszałem już 
od niego różne skargi, ale jak do tej pory nie dotarły do mnie żadne ze 
strony "try" :)

--
Przemysław Pokrywka

Przemek Pokrywka napisał(a):
> Adam Przybyłek napisał(a):
> 
>> Nieelegancko, bo chcesz sprowadzic "try" do poziomu instrukcji 
>> sterujacych
>> "if", "for", "while".
> 
> 
> A czy w ten sposób ujmę mu czegokolwiek? :)
> W trakcie programowania z uwagą wsłuchuję się w mój kod i słyszałem już 
> od niego różne skargi, ale jak do tej pory nie dotarły do mnie żadne ze 
> strony "try" :)

Niektórzy uważają, że sytuacje wyjątkowe to te, które nie wynikają z 
dokumentacji. Jeżeli więc dokumentacja mówi, że program ma sprawdzić czy 
plik istnieje, to można powinien być kod typu

if(File(filePath).Exists)
{
	try
	{
		using(File f = new File(filePath))
		{
			//tu operacje na pliku
		}
	}
	catch(Exception)
	{
		//obsłużenie nieoczekiwanego błędu
	}
}
else
{
	//np. ponowne pobranie ścieżki
}

A jeżeli założymy że dokumentacja nie mówi, że program nie ma sprawdzać 
istnienia pliku, to po prostu:

	try
	{
		using(File f = new File(filePath))
		{
			//tu operacje na pliku
		}
	}
	catch(Exception)
	{
		//obsłużenie nieoczekiwanego błędu
	}

Pozdrawiam
			
-- 
Grzegorz Gruza
Odpowiadając usuń "spamerom_nie." z adresu!!!

"Grzesiek G." <gruza@spamerom_nie.priv4.onet.pl> wrote:

> Jeżeli więc dokumentacja mówi, że program ma sprawdzić czy
> plik istnieje, to można powinien być kod typu

Zupelnie bez sensu.

Jezeli po "elese" stoi to samo co w "catch" to zmarnowalismy kilka linii
kodu, bo program zachowuje sie identycznie.

Jezeli zas stoi cos innego, to program staje sie "nieciagly". Tzn. male
zaburzenia w czasie wykonywania akcji, powoduja, ze zachowanie programu jest
inne. Program dziala niedeterministycznie (nie jestesmy w stanie przewidziec
wyniku).


mp

Użytkownik "Przemek Pokrywka" <adres@zastrzezony.com> napisał w wiadomości
news:e0elup$ad0$1@news.onet.pl...
> Adam Przybyłek napisał(a):
> > Nieelegancko, bo chcesz sprowadzic "try" do poziomu instrukcji
sterujacych
> > "if", "for", "while".
>
> A czy w ten sposób ujmę mu czegokolwiek? :)
> W trakcie programowania z uwagą wsłuchuję się w mój kod i słyszałem już
> od niego różne skargi, ale jak do tej pory nie dotarły do mnie żadne ze
> strony "try" :)
>

"Try" to jest taki ukrytu "GO TO".

>
>Użytkownik "Przemek Pokrywka" <adres@zastrzezony.com> napisał w wiadomości
>news:e0elup$ad0$1@news.onet.pl...
>> Adam Przybyłek napisał(a):
>> > Nieelegancko, bo chcesz sprowadzic "try" do poziomu instrukcji
>sterujacych
>> > "if", "for", "while".
>>
>> A czy w ten sposób ujmę mu czegokolwiek? :)
>> W trakcie programowania z uwagą wsłuchuję się w mój kod i słyszałem już
>> od niego różne skargi, ale jak do tej pory nie dotarły do mnie żadne ze
>> strony "try" :)
>>
>
>"Try" to jest taki ukrytu "GO TO".

Slucham..?


A.
-- 
============= P o l N E W S ==============
     archiwum i przeszukiwanie newsów
        http://www.polnews.pl

Michal Przybylek napisał(a):
> "Grzesiek G." <gruza@spamerom_nie.priv4.onet.pl> wrote:
> 
> 
>>Jeżeli więc dokumentacja mówi, że program ma sprawdzić czy
>>plik istnieje, to można powinien być kod typu
> 
> 
> Zupelnie bez sensu.
> 
> Jezeli po "elese" stoi to samo co w "catch" to zmarnowalismy kilka linii
> kodu, bo program zachowuje sie identycznie.
> 

Nie zawsze. Bo jeżeli np. wcześniej wspomniany plik powinno się dać 
otworzyć (sprawdzone if-em) a się nie daje, to program może głośno 
krzyczeć, a jeżeli sprawdzenie if-em nie wyjdzie to delikatnie 
sugerować. Jeżeli użytkownik tak chce (i za to płaci :-)) i jest to tak 
opisane w dokumentacji to czemu taka implementacja jest zła?

> Jezeli zas stoi cos innego, to program staje sie "nieciagly". Tzn. male
> zaburzenia w czasie wykonywania akcji, powoduja, ze zachowanie programu jest
> inne. Program dziala niedeterministycznie (nie jestesmy w stanie przewidziec
> wyniku).

Nie bardzo rozumiem. Co to są małe zaburzenia? Być może na podstawie 
przedstawionego przeze mnie pseudokodu nie jesteśmy w stanie przewidzieć 
wyniku, ale wrzuciłem go tylko dla ilustracji.

Ja po prostu prezentuję swój pogląd znajdujący się pomiędzy 
bezwzględnymi: "zawsze if" oraz "zawsze wyjątek". I nie jestem jedyny z 
takim poglądem, w tym wątku.

Pozdrawiam

-- 
Grzegorz Gruza
Odpowiadając usuń "spamerom_nie." z adresu!!!

Grzesiek G. napisał(a):
> Niektórzy uważają, że sytuacje wyjątkowe to te, które nie wynikają z 
> dokumentacji. Jeżeli więc dokumentacja mówi, że program ma sprawdzić czy 
> plik istnieje, to można powinien być kod typu
> 
[...]

Zgaduję, że intencją Kolegi było zaznaczenie, że klient (który płaci i 
wymaga) życzy sobie rozgraniczania sytuacji nieodnalezienia pliku od 
wystąpienia innych błędów wejścia/wyjścia. Zdanie o kliencie, który 
umieszcza w dokumentacji nakaz sprawdzenia występowania pliku budzi we 
mnie skrajne emocje - od pokładania się ze śmiechu z absurdalnego żartu 
po osłupienie z przerażenia nad jego bezdennym idiotyzmem. Któż na 
świecie interesuje się tym, co robi w środku metoda (jeśli tylko 
wykonuje swoje zadanie).

Zarówno w przypadku gdy klient życzy sobie rozróżniania tych przypadków 
na poziomie sygnatury metody (w jakikolwiek sposób), jak i wtedy, gdy 
jest mu to obojętne, daje się to elegancko obsłużyć za pomocą wyjątków.

try {
	// operacje na plikach
	// ...
} catch (FileNotFoundException notFound) {
	// obsługa braku pliku na dysku
} catch (IOException otherIO) {
	// obsługa innych błędów wejścia/wyjścia
}

--
Pozdrawiam,
Przemysław Pokrywka

Przemek Pokrywka napisał(a):
> Grzesiek G. napisał(a):
> 
>> Niektórzy uważają, że sytuacje wyjątkowe to te, które nie wynikają z 
>> dokumentacji. Jeżeli więc dokumentacja mówi, że program ma sprawdzić 
>> czy plik istnieje, to można powinien być kod typu
>>
> [...]
> 
> Zgaduję, że intencją Kolegi było zaznaczenie, że klient (który płaci i 
> wymaga) życzy sobie rozgraniczania sytuacji nieodnalezienia pliku od 
> wystąpienia innych błędów wejścia/wyjścia. Zdanie o kliencie, który 
> umieszcza w dokumentacji nakaz sprawdzenia występowania pliku budzi we 
> mnie skrajne emocje - od pokładania się ze śmiechu z absurdalnego żartu 
> po osłupienie z przerażenia nad jego bezdennym idiotyzmem. Któż na 
> świecie interesuje się tym, co robi w środku metoda (jeśli tylko 
> wykonuje swoje zadanie).
> 

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

Problem istnienia pliku jest tu tylko problemem hipotetycznym, którym 
posłużyłem w nawiązaniu do odpowiedzi przedmówcy.

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.


> Zarówno w przypadku gdy klient życzy sobie rozróżniania tych przypadków 
> na poziomie sygnatury metody (w jakikolwiek sposób), jak i wtedy, gdy 
> jest mu to obojętne, daje się to elegancko obsłużyć za pomocą wyjątków.
> 
> try {
>     // operacje na plikach
>     // ...
> } catch (FileNotFoundException notFound) {
>     // obsługa braku pliku na dysku
> } catch (IOException otherIO) {
>     // obsługa innych błędów wejścia/wyjścia
> }

Tutaj jasnym jest, że tak elegancko to można zrobić, bo istnieje wyjątek 
FileNotFound i bardziej ogólny IOExcpeption. Ale co w sytuacji, gdy 
wszystkie błędy wywoływania zapytań bazy danych zwracają wyjątek 
SqlException?

Pozdrawiam

-- 
Grzegorz Gruza
Odpowiadając usuń "spamerom_nie." z adresu!!!

"Grzesiek G." <gruza@spamerom_nie.priv4.onet.pl> writes:

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

To, sytuacja była przewidziana w specyfikacji na którymś poziomie
abstrakcji, nie ma nic do rzeczy.

Warto użyć wyjątków wtedy, kiedy obsługa sytuacji będzie zwykle
daleko od miejsca jej wykrycia, czyli kiedy bezpośrednim skutkiem tej
sytuacji będzie przerwanie części obliczeń, oraz (w części języków,
m.in. w C++ i Javie, w których rzucanie wyjątków jest względnie
drogie) kiedy ta sytuacja jest rzadka.

-- 
   __("<         Marcin Kowalczyk
   \__/       qrczak@knm.org.pl
    ^^     http://qrnik.knm.org.pl/~qrczak/

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

>Warto użyć wyjątków wtedy, kiedy obsługa sytuacji będzie zwykle
>daleko od miejsca jej wykrycia, czyli kiedy bezpośrednim skutkiem tej
>sytuacji będzie przerwanie części obliczeń, oraz (w części języków,
>m.in. w C++ i Javie, w których rzucanie wyjątków jest względnie
>drogie)

Z ciekawosci: co tam jest takiego drogiego?

A.
-- 
============= P o l N E W S ==============
     archiwum i przeszukiwanie newsów
        http://www.polnews.pl

"Aleksander Galicki" <no@no.com> writes:

>>Warto użyć wyjątków wtedy, kiedy obsługa sytuacji będzie zwykle
>>daleko od miejsca jej wykrycia, czyli kiedy bezpośrednim skutkiem tej
>>sytuacji będzie przerwanie części obliczeń, oraz (w części języków,
>>m.in. w C++ i Javie, w których rzucanie wyjątków jest względnie
>>drogie)
>
> Z ciekawosci: co tam jest takiego drogiego?

W C++ akcje do wykonania przy okazji wyjątku są bardzo powszechne
(nietrywialne destruktory zmiennych lokalnych), więc implementacje C++
starają się tak realizować wyjątki, żeby wejście do takiego niejawnego
'try' ani wyjście z niego nic nie kosztowało.

Jeśli ma nie być dodatkowych narzutów związanych z 'try', to przy
typowej konwencji wołania funkcji jedynym sposobem na stwierdzenie,
co robić w przypadku wyjątku, jest obejrzenie każdej ramki stosu
między 'throw' a 'try' i znalezienie tych informacji na podstawie
adresu powrotu w "mapach kodu" (które mogą być zaalokowane
statycznie). Przy czym oglądać trzeba również te ramki stosu,
w których nie ma żadnych 'try', nawet niejawnych, bo a priori nie
wiadomo, które ramki takie są, a adresy powrotu trzeba wyszukiwać
w jakichś statycznych słownikach.

W implementacjach innych języków bywa tak, że wejście do 'try'
i wyjście z 'try' powoduje wykonanie dodatkowych instrukcji.
Na przykład w OCamlu przy wejściu do 'try' bieżący wierzchołek stosu
jest zapamiętywany w odpowiednim "rejestrze", a adres kodu obsługi
wyjątku i poprzednia wartość tego "rejestru" - na stosie. Za to
'throw' jest szybkie: zwijamy stos do najbliższego 'try' jednym
ruchem, czyli koszt jest proporcjonalny do liczby 'try', z których
trzeba wyskoczyć, a nie do liczby ramek stosu między 'throw' a 'try'.

W Javie nie ma tylu niejawnych 'try' co w C++, więc można tam
realizować wyjątki podobnie jak np. w OCamlu. Ale wydaje mi się,
że tradycyjnie wyjątki są obsługiwane podobnie jak w C++.

-- 
   __("<         Marcin Kowalczyk
   \__/       qrczak@knm.org.pl
    ^^     http://qrnik.knm.org.pl/~qrczak/

>"Aleksander Galicki" <no@no.com> writes:
>
>>>Warto użyć wyjątków wtedy, kiedy obsługa sytuacji będzie zwykle
>>>daleko od miejsca jej wykrycia, czyli kiedy bezpośrednim skutkiem tej
>>>sytuacji będzie przerwanie części obliczeń, oraz (w części języków,
>>>m.in. w C++ i Javie, w których rzucanie wyjątków jest względnie
>>>drogie)
>>
>> Z ciekawosci: co tam jest takiego drogiego?
>
>W C++ akcje do wykonania przy okazji wyjątku są bardzo powszechne
>(nietrywialne destruktory zmiennych lokalnych), więc implementacje C++
>starają się tak realizować wyjątki, żeby wejście do takiego niejawnego
>'try' ani wyjście z niego nic nie kosztowało.
>
>Jeśli ma nie być dodatkowych narzutów związanych z 'try', to przy
>typowej konwencji wołania funkcji jedynym sposobem na stwierdzenie,
>co robić w przypadku wyjątku, jest obejrzenie każdej ramki stosu
>między 'throw' a 'try' i znalezienie tych informacji na podstawie
>adresu powrotu w "mapach kodu" (które mogą być zaalokowane
>statycznie). Przy czym oglądać trzeba również te ramki stosu,
>w których nie ma żadnych 'try', nawet niejawnych, bo a priori nie
>wiadomo, które ramki takie są, a adresy powrotu trzeba wyszukiwać
>w jakichś statycznych słownikach.
>

Ale Javy to nie dotyczy chyba ..?

A.
-- 
============= P o l N E W S ==============
     archiwum i przeszukiwanie newsów
        http://www.polnews.pl

>>
>>Jeśli ma nie być dodatkowych narzutów związanych z 'try', to przy
>>typowej konwencji wołania funkcji jedynym sposobem na stwierdzenie,
>>co robić w przypadku wyjątku, jest obejrzenie każdej ramki stosu
>>między 'throw' a 'try' i znalezienie tych informacji na podstawie
>>adresu powrotu w "mapach kodu" (które mogą być zaalokowane
>>statycznie). Przy czym oglądać trzeba również te ramki stosu,
>>w których nie ma żadnych 'try', nawet niejawnych, bo a priori nie
>>wiadomo, które ramki takie są, a adresy powrotu trzeba wyszukiwać
>>w jakichś statycznych słownikach.
>>
>
>Ale Javy to nie dotyczy chyba ..?
>


le, ze tak powiem, obciach. Przepraszam, nie wylogowalem sie z konta mojej TŻ :-)



A.
-- 
============= P o l N E W S ==============
     archiwum i przeszukiwanie newsów
        http://www.polnews.pl

Aleksander Galicki wrote:
> le, ze tak powiem, obciach. Przepraszam, nie wylogowalem sie z konta mojej TŻ :-)

Aż dłuższą chwilę zastanowienia miałem... przy całym szacunku do 
ciekawych doświadczeń i ogólnego życiowego rozsądku Immony nie 
podejrzewałem jej aż o taką wszechstronność :).

A sam wątek, nota bene, jest dość jałowy.

Java ma już swoje lata (zresztą z doświadczeń Java skorzystał też C# i 
.NET(*)), pewne best practices zdążyły się już wykrystalizować:

http://www-128.ibm.com/developerworks/java/library/j-ejbexcept.html
http://www.onjava.com/pub/a/onjava/2003/11/19/exceptions.html?page=1

i nie ma co odkrywać koła na nowo. Bardzo rozbawił mnie kiedyś ten artykuł:
http://jdn.pl/node/387
którego tezy są wprawdzie dość niesprawiedliwie wycelowane w Polaków, 
ale w ogólności coś w tym jest, że serwisowi thedailywtf.com nie brakuje 
treści do publikowania ;).

Jeśli ktoś ma wątpliwości jak obsługiwać błędy w warstwie DAO, a ten 
temat przewija się przez wątek, to warto zobaczyć, jak to zostało 
zrobione np. w Hibernate, TopLink czy Spring. A swoją drogą to poza 
wybitnie kuriozalnymi przypadkami przepychania checked exceptions z 
warstwy obsługi danych do samego widoku przez różne dziwne rzeczy po 
drodze, nie spotkałem się nigdy z sytuacją, żeby pomysł na obsługę 
wyjątków był aż tak zły, żeby powodowało to jakiś widoczny narzut kodu 
czy animozje projektowe.

(*) .NET zrezygnował z checked exceptions, co z jednej strony może mieć 
pewne zalety, z drugiej zaś biedni .netowi programiści nadal nie wiedzą, 
co może wylecieć z nieznanej im metody, o ile autor nie zadbał o 
precyzyjną dokumentację.

pozdrawiam,
-- 
mgl

Aleksander Galicki wrote:

>>Warto użyć wyjątków wtedy, kiedy obsługa sytuacji będzie zwykle
>>daleko od miejsca jej wykrycia, czyli kiedy bezpośrednim skutkiem tej
>>sytuacji będzie przerwanie części obliczeń, oraz (w części języków,
>>m.in. w C++ i Javie, w których rzucanie wyjątków jest względnie
>>drogie)
> 
> Z ciekawosci: co tam jest takiego drogiego?

W Javie właściwie jedyny pewny koszt dodatkowy, to utworzenie instancji 
wyjątku, który jest rzucany. Nie da się tego kosztu pominąć w jakiś 
sensowny sposób, za każdym razem tworzony jest nowy wyjątek, który poza 
dodatkowymi atrybutami, przechowuje stos wywołań (bywa często, że 
niemały). Stąd i koszt w porównaniu z nie rzucaniem wyjątku jest tu w 
oczywisty sposób większy.

Cała reszta to już sprawy zalezne od implementacji maszyny wirtualnej, 
więc i w kontekście porównania kosztów jest bez znaczenia.


piotr

"Immona" <c.oleszkiewicz@na.gmailu> writes:

>>Jeśli ma nie być dodatkowych narzutów związanych z 'try', to przy
>>typowej konwencji wołania funkcji jedynym sposobem na stwierdzenie,
>>co robić w przypadku wyjątku, jest obejrzenie każdej ramki stosu
>>między 'throw' a 'try' i znalezienie tych informacji na podstawie
>>adresu powrotu w "mapach kodu" (które mogą być zaalokowane
>>statycznie). Przy czym oglądać trzeba również te ramki stosu,
>>w których nie ma żadnych 'try', nawet niejawnych, bo a priori nie
>>wiadomo, które ramki takie są, a adresy powrotu trzeba wyszukiwać
>>w jakichś statycznych słownikach.
>
> Ale Javy to nie dotyczy chyba ..?

Hmm, właściwie to nie wiem, dlaczego wyjątki w C++ są wolne. Moje
rozumowanie było błędne: te ramki stosu i tak trzeba było kiedyś
utworzyć, więc asymptotyczny koszt rzucania wyjątku nie ma wpływu na
asymptotyczny koszt programu. Jednak eksperyment pokazuje, że rzucanie
wyjątku w GCC rzeczywiście jest wolne:

           | OCaml | C++ (GCC) | Java (Sun) |
-----------+-------+-----------+------------+
 pusty     | 0.003 |   0.004   |   0.246    |
 wynikiem  | 0.408 |   0.140   |   0.328    |
 wyjątkiem | 0.614 |  70.310   |   1.696    |

Programy niżej. Czasy w sekundach. Pusty program ma pętlę długości 0;
w ten sposób można wyeliminować czas uruchomienia programu. "Wynikiem"
przekazuje wynik w typie bool, "wyjątkiem" przekazuje wynik wyjątkiem.
Wygląda na to, że wyjątki w Javie Suna są dużo szybsze niż w GCC,
ale wolniejsze niż w OCamlu. Z czasów można wywnioskować, że żaden
kompilator nie wyoptymalizował całej pętli, więc mimo że to
microbenchmark, wynik wydaje się mierzyć prawdziwy koszt wyjątków.

----------------------------------------------------------------------
exception Exn

let test1 x y = x < y

let test2 x y = if x < y then raise Exn

let _ =
  let count = ref 0 in
  for i = 0 to 9999999 do
    (* if test1 i 5000000 then count := !count + 1 *)
    try test2 i 5000000 with Exn -> count := !count + 1
  done;
  print_int !count; print_newline()
......................................................................
ocamlopt exc-ml.ml -o exc-ml
time ./exc-ml
(ocaml-3.09.0)
----------------------------------------------------------------------
#include <iostream>

bool test1(int x, int y) {
   return x < y;
}

void test2(int x, int y) {
   if (x < y) throw 0;
}

int main() {
   int count = 0;
   for (int i = 0; i < 10000000; ++i) {
      // if (test1(i, 5000000)) ++count;
      try {test2(i, 5000000);} catch (int x) {++count;}
   }
   std::cout << count << std::endl;
}
......................................................................
g++ -O2 exc-cc.cc -o exc-cc
time ./exc-cc
(gcc-4.1.0)
----------------------------------------------------------------------
class ExcJava {
   static RuntimeException exn = new RuntimeException();

   static boolean test1(int x, int y) {
      return x < y;
   }

   static void test2(int x, int y) {
      if (x < y) throw exn;
   }

   public static void main(String[] args) {
      int count = 0;
      for (int i = 0; i < 10000000; ++i) {
         // if (test1(i, 5000000)) ++count;
         try {test2(i, 5000000);} catch (RuntimeException x) {++count;}
      }
      System.out.println(count);
   }
}
......................................................................
javac ExcJava.java
time java ExcJava
(java-sun-1.5.0.01)
----------------------------------------------------------------------

-- 
   __("<         Marcin Kowalczyk
   \__/       qrczak@knm.org.pl
    ^^     http://qrnik.knm.org.pl/~qrczak/

"Marcin 'Qrczak' Kowalczyk" <qrczak@knm.org.pl> wrote:

> Hmm, właściwie to nie wiem, dlaczego wyjątki w C++ są wolne.

> g++ -O2 exc-cc.cc -o exc-cc

A jak wyglada assembler ?


mp

Użytkownik "mgl" <ask@for.email.com> napisał w wiadomości
news:e0tj9e$92e$1@news.dialog.net.pl...
> Aleksander Galicki wrote:
>[...] Java ma już swoje lata (zresztą z doświadczeń Java skorzystał też C#
i
> .NET(*)), pewne best practices zdążyły się już wykrystalizować:
>
> http://www-128.ibm.com/developerworks/java/library/j-ejbexcept.html
> [...]

Bardzo dobry przyklad - Listing 1, wiersze 111-114:

while (itemIter.hasNext()) {
  OrderItem item = (OrderItem) itemIter.getNext();
  item.remove();
}

Rozumiem, ze kolega Przemek napisal by ten fragment tak:

while (true) {
  OrderItem item = (OrderItem) itemIter.getNext();
  item.remove();
}
...
catch (NoSuchElementException nse) {}


Adam

"Michal Przybylek" <mrp@neostrada.pl> writes:

>> g++ -O2 exc-cc.cc -o exc-cc
>
> A jak wyglada assembler ?

http://qrnik.knm.org.pl/~qrczak/tmp/exc-cc.s

Dla porównania asembler wygenerowany przez OCamla:
http://qrnik.knm.org.pl/~qrczak/tmp/exc-ml.s

-- 
   __("<         Marcin Kowalczyk
   \__/       qrczak@knm.org.pl
    ^^     http://qrnik.knm.org.pl/~qrczak/

"Marcin 'Qrczak' Kowalczyk" <qrczak@knm.org.pl> wrote in message:

> Hmm, właściwie to nie wiem, dlaczego wyjątki w C++ są wolne. Moje
> rozumowanie było błędne: te ramki stosu i tak trzeba było kiedyś
> utworzyć, więc asymptotyczny koszt rzucania wyjątku nie ma wpływu na
> asymptotyczny koszt programu. Jednak eksperyment pokazuje, że rzucanie
> wyjątku w GCC rzeczywiście jest wolne:

Bo GCC od zawsze byl w tej materii spie..

AK 

On Tue, 04 Apr 2006 14:15:13 +0200, Marcin 'Qrczak' Kowalczyk
<qrczak@knm.org.pl> wrote:
 
>
>Hmm, w³a¶ciwie to nie wiem, dlaczego wyj±tki w C++ s± wolne. Moje
>rozumowanie by³o b³êdne: te ramki stosu i tak trzeba by³o kiedy¶
>utworzyæ, wiêc asymptotyczny koszt rzucania wyj±tku nie ma wp³ywu na
>asymptotyczny koszt programu. Jednak eksperyment pokazuje, ¿e rzucanie
>wyj±tku w GCC rzeczywi¶cie jest wolne:
    

A pod prawdziwym kompilatorem?...

A.L.

Marcin 'Qrczak' Kowalczyk wrote:

> (...) Z czasów można wywnioskować, że żaden
> kompilator nie wyoptymalizował całej pętli, więc mimo że to
> microbenchmark, wynik wydaje się mierzyć prawdziwy koszt wyjątków.

Nie wiem jak w pozostałych przypadkach, odnośnie Javy myślę jednak, że 
to wniosek tak samo prawdopodobny, jak błędny. JIT sporo się tu 
napracował -- blisko 90% czasu spędzają wszystkie Twoje warianty w 
natywnym main (widać to ładnie z opcją -Xprof).

Poza tym, nie rozumiem dlaczego pomijasz optymalizacje?
Przecież to co robi z tym optymalizator jest za darmo, więc dlaczego nie 
uznajesz tego za rzeczywisty koszt? Jest to o tyle ważne, że akurat w 
przypadku Javy warianty "wynikiem" i "wyjątkiem" z opcją -server śmigają 
identycznie -- co dowodzi, że tworzenie wyjątków jest w Javie jedynym 
dodatkowym kosztem...


piotr

Piotr Kobzda <pikob@gazeta.pl> writes:

> Poza tym, nie rozumiem dlaczego pomijasz optymalizacje?

Zależy jakie. Gdyby kompilator obliczył cały wynik w czasie kompilacji,
to taka optymalizacja przechodzi tylko w sztucznym mikrobenchmarku,
a w rzeczywistym kodzie z reguły nie ma szans. Ale jeśli polega tylko
na wyeliminowaniu rzucenia wyjątku, to być może przy innych użyciach,
kiedy rzucenie wyjątku jest bliskie złapania, też by tak było, i wtedy
warto na nią pozwolić. Wniosek: przydałby się bardziej realistyczny test.

> Jest to o tyle ważne, że akurat w przypadku Javy warianty "wynikiem"
> i "wyjątkiem" z opcją -server śmigają identycznie -- co dowodzi, że
> tworzenie wyjątków jest w Javie jedynym dodatkowym kosztem...

Hmm. Z -server pusty program wykonuje się tak samo długo jak wersja
bez wyjątku (0.35), a wersja z wyjątkiem trochę dłużej (0.38-0.43).
Nie umiem tego zinterpretować.

-- 
   __("<         Marcin Kowalczyk
   \__/       qrczak@knm.org.pl
    ^^     http://qrnik.knm.org.pl/~qrczak/

AL. <alewando@ziuta66.com> writes:

> A pod prawdziwym kompilatorem?...

Jeśli masz na myśli VC++, to nie mam jak sprawdzić, bo on nie działa
pod prawdziwym systemem operacyjnym.

-- 
   __("<         Marcin Kowalczyk
   \__/       qrczak@knm.org.pl
    ^^     http://qrnik.knm.org.pl/~qrczak/

On Tue, 04 Apr 2006 17:25:37 +0200, Marcin 'Qrczak' Kowalczyk
<qrczak@knm.org.pl> wrote:

>AL. <alewando@ziuta66.com> writes:
>
>> A pod prawdziwym kompilatorem?...
>
>Je¶li masz na my¶li VC++, to nie mam jak sprawdziæ, bo on nie dzia³a
>pod prawdziwym systemem operacyjnym.

A nie masz jakichs prawdziwych systemow?... Linuksa do takowych nei
zaliczam.

A.L>

P.S> Mozna prosic o definicje "prawdziwego systemu operacyjnego? W
sensie MIMUW?...

Marcin 'Qrczak' Kowalczyk wrote:

>>Jest to o tyle ważne, że akurat w przypadku Javy warianty "wynikiem"
>>i "wyjątkiem" z opcją -server śmigają identycznie -- co dowodzi, że
>>tworzenie wyjątków jest w Javie jedynym dodatkowym kosztem...
> 
> Hmm. Z -server pusty program wykonuje się tak samo długo jak wersja
> bez wyjątku (0.35), a wersja z wyjątkiem trochę dłużej (0.38-0.43).
> Nie umiem tego zinterpretować.

To może zobacz moje rezultaty (kod poniżej):

C:\Eclipse\Workspaces\testy\benchmarks\bin>c:\java\jdk1.5.0_06\bin\java 
-Xprof -server ExcJava 50000000
..............................
ExcJava$1 t/count=0.768317764 t/10=1.92079441E7
ExcJava$2 t/count=1.809410972 t/10=4.52352743E7
ExcJava$3 t/count=1.798130212 t/10=4.49532553E7
..............................
ExcJava$1 t/count=0.696917624 t/10=1.74229406E7
ExcJava$2 t/count=1.794431416 t/10=4.48607854E7
ExcJava$3 t/count=1.786413636 t/10=4.46603409E7

Flat profile of 21.66 secs (810 total ticks): main

   Interpreted + native   Method
   0.9%     0  +     7    java.lang.System.arraycopy
   0.1%     1  +     0    ExcJava$1.run
   0.1%     1  +     0    ExcJava.<clinit>
   0.1%     0  +     1    java.io.FileOutputStream.writeBytes
   1.2%     2  +     8    Total interpreted

      Compiled + native   Method
  41.7%   338  +     0    ExcJava$3.run
  40.4%   327  +     0    ExcJava$2.run
  16.4%   133  +     0    ExcJava$1.run
  98.5%   798  +     0    Total compiled

   Thread-local ticks:
   0.2%     2             Class loader


Flat profile of 0.01 secs (1 total ticks): DestroyJavaVM

   Thread-local ticks:
100.0%     1             Blocked (of total)


Global summary of 21.68 seconds:
100.0%   812             Received ticks
   0.1%     1             Compilation
   0.2%     2             Class loader



piotr

-- 

public class ExcJava {

    private static final RuntimeException exn = new RuntimeException();

    static boolean test1(int x, int y) {
       return x < y;
    }

    static void test2(int x, int y) {
       if (x < y)
          throw exn;
    }

    public static void main(String[] args) {

       final int retrys = 2;
       final int loops = 10;

       final int m = args.length > 0
             ? Integer.parseInt(args[0]) : 10000000;
       final int n = args.length > 1
             ? Integer.parseInt(args[1]) : m / 2;


       abstract class Test {

          volatile int count;
          long t;

          abstract void run();

          void perform() {
             long t = System.nanoTime();
             run();
             this.t = System.nanoTime() - t;
          }

          void reset() {
             count = 0;
             t = 0;
          }

          @Override
          public String toString() {
             return getClass().getName()
                   + (count % n != 0
                         ? " count=" + count : "")
                   + " t=" + t;
          }
       }

       Test[] tests = new Test[] {
             new Test() {
                void run() {
                   for (int i = 0; i < n; ++i) {
                      ++count;
                   }
                };
             },
             new Test() {
                void run() {
                   for (int i = 0; i < m; ++i) {
                      if (test1(i, n))
                         ++count;
                   }
                };
             },
             new Test() {
                void run() {
                   for (int i = 0; i < m; ++i) {
                      try {
                         test2(i, n);
                      } catch (RuntimeException x) {
                         ++count;
                      }
                   }
                };
             },
          };


       for(int i = 0; i < retrys; ++i) {

          for(int j = 0; j < loops; ++j) {
             for(Test t : tests) {
                t.perform();
                System.out.print(".");
                if (t.count % n != 0)
                   System.out.println(t);
             }
          }
          System.out.println();

          for(Test t : tests) {
             System.out.println(t.getClass().getName()
                   + " t/count=" + (double)t.t / t.count
                   + " t/" + loops + "=" + (double)t.t / loops);
             t.reset();
          }
       }
    }
}

PT AL pisze:

> P.S. Mozna prosic o definicje "prawdziwego systemu operacyjnego? W
> sensie MIMUW?...

...a skoro już tak off-topic, to ja chciałbym poznać definicję
"prawdziwego systemu operacyjnego" sensu A.L. (naprawdę mnie to
ciekawi; podobnie jak kryteria uznania czegoś za prawdziwy bądź
nieprawdziwy kompilator).

Jubal

-- 
[ Miros/law L Baran, baran-at-knm-org-pl, neg IQ, cert AI ] [ 0101010 is ]
[ BOF2510053411, http://hell.pl/baran/tek/, alchemy pany! ] [ The Answer ] 

    Alliance, n.:
            In international politics, the union of two thieves who
            have their hands so deeply inserted in each other's pocket
            that they cannot separately plunder a third.
                    -- Ambrose Bierce, ,,The Devil's Dictionary''

"Marcin 'Qrczak' Kowalczyk" <qrczak@knm.org.pl> wrote:

> > A jak wyglada assembler ?
>
> http://qrnik.knm.org.pl/~qrczak/tmp/exc-cc.s

Dzieki. Choc niewiele pomoglo :-)

> Dla porównania asembler wygenerowany przez OCamla:
> http://qrnik.knm.org.pl/~qrczak/tmp/exc-ml.s

W OCaml'u mniej wiecej wiem jak sa obslugiwane wyjatki.


mp

"Miros/law L. Baran" <baran@hell.pl> wrote:

> ...a skoro już tak off-topic, to ja chciałbym poznać definicję
> "prawdziwego systemu operacyjnego" sensu A.L.

Moge sie pokusic o taka definicje z punktu widzenia developera (bo na tym 
sie znam).
Prawdziwy system operacyjny to taki ktory dostarcza 
standardowo/defaultowo/itp
wbudowana w system dojrzala technologie komponentowa.
W dodatku technologia ta powinna byc wielojezykowa (w sensie jezykow 
programowania
oczywiscie).

Takim systemem jest np. wlasnie Windows (bo posiada COM/DCOM i .NET).

> (naprawdę mnie to ciekawi; podobnie jak kryteria uznania czegoś za
>  prawdziwy bądź nieprawdziwy kompilator).

Prawdziwy kompilator to taki ktory przynajmniej:
1. jest zgodny ze standardem/raportem jezyka (gcc nie jest).
2. jest bezbledny w podstawowych konstrukcjach j.progr (gcc nie jest).
3. jest efektywny w podstawowych konstrukcjach j.progr (gcc nie jest).
3. dobrze wspiera nowoczesne technologie komponentowe (gcc nie wspiera 
zadnej).

AK

"Miros/law L. Baran" <baran@hell.pl> writes:

> PT AL pisze:
>
>> P.S. Mozna prosic o definicje "prawdziwego systemu operacyjnego? 
>> W sensie MIMUW?...
>
> ...a skoro już tak off-topic, to ja chciałbym poznać definicję
> "prawdziwego systemu operacyjnego" sensu A.L. (naprawdę mnie to
> ciekawi; podobnie jak kryteria uznania czegoś za prawdziwy bądź
> nieprawdziwy kompilator).

Prawdziwe kryteria?

Adam Przybyłek napisał(a):
> Bardzo dobry przyklad - Listing 1, wiersze 111-114:
> 
> while (itemIter.hasNext()) {
>   OrderItem item = (OrderItem) itemIter.getNext();
>   item.remove();
> }
> 
> Rozumiem, ze kolega Przemek napisal by ten fragment tak:
> 
> while (true) {
>   OrderItem item = (OrderItem) itemIter.getNext();
>   item.remove();
> }
> ...
> catch (NoSuchElementException nse) {}

:-)

"Kiedy mędrzec wskazuje na Księżyc, niektórzy widzą tylko palec" 
(zaadoptowane z dalekowschodniego powiedzenia)

Pisałem wcześniej, że użycie try/catch jest częstokroć pożądane, bo 
pozwala na znacznie wyraźniejsze zaznaczenie intencji kodu - jego 
scenariusza podstawowego oraz scenariuszy awaryjnych.
Osobiście nie użyłbym try/catch gdyby miało to zaciemnić przeznaczenie 
kodu. Przeróbka autorstwa Kolegi to robi, bo mylnie sugeruje, że 
pozytywnym scenariuszem wykonania jest nieprzerwane pobieranie i 
usuwanie elementu z iteratora. Prawdziwą intencją jest usunięcie 
wszystkich (a więc jedynie tych istniejących) elementów z iteratora, co 
jest bardzo wyraźnie komunikowane przez oryginalny fragment kodu.

Tak więc mimo że przeróbka jest funkcjonalnie równoważna, to kod jest 
zaciemniony, dlatego nie wprowadziłbym jej (nawet mimo braku 
wykorzystania konstrukcji try/catch).

--
Pozdrawiam,
Przemysław Pokrywka

>Aleksander Galicki wrote:
>> le, ze tak powiem, obciach. Przepraszam, nie wylogowalem sie z konta mojej
>TŻ :-)
>
>Aż dłuższą chwilę zastanowienia miałem... przy całym szacunku do 
>ciekawych doświadczeń i ogólnego życiowego rozsądku Immony nie 
>podejrzewałem jej aż o taką wszechstronność :).
>

Ja sie tez zdziwilem :) Zreszta, wyjartkami w Javie zadna normalna osoba spoza
branzy sie zainteresowac chyba nie da. 

A.
-- 
============= P o l N E W S ==============
     archiwum i przeszukiwanie newsów
        http://www.polnews.pl

Przemek Pokrywka napisał(a):
> 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.

Aż dziw mnie bierze (i przyznam że zazdroszczę) :-), że się nie 
spotkałeś ani razu :-). Miałem do wykonania program walidujący i 
importujący plik csv do bazy danych. Wyjściem z nieudanej walidacji był 
raport błędów. Program był zrobiony tak, że przetwarzał plik do 
struktury obiektowej, którą obrabiał i zapisywał w bazie. Plik był 
poprawny, jeśli dawał się przekształcić do struktury obiektowej.

Niestety, rzeczywiste pliki okazały się fatalne. Tworzyło je pare osób w 
  MS Office i różnych Open Officach, także walidacja stała się ważna. Co 
gorsza za długo trwała (kilka minut), co bardzo złościło klienta. Była 
napisana poczętkowo w stylu:
try
{
	zmienna = decimal.Parse(napis);
	...
}
catch(InvalidFormatException exc)
{
	logger.log("Nie można skonwertować ...);
}

została przepisana na:
if(decimal.TryParse(napis)
{
	zmienna = decimal.Parse(Napis);
}
else
{
	logger.log("Nie można skonwertować ...);
}
Czas wykonania walidacji skrócił się do kilkudziesięciu sekund.


> Jeszcze raz za mistrzem Knuthem powtórzę, że "premature optimization is 
> the root of all evil"
> 

Z tą tezą też się zgadzam. Ale jeżeli np. w naszej aplikacji WWW strony 
ładują się u klienta kilkadziesiąt sekund, to nie czekamy na 
uzupełnienie specyfikacji uwagami o wydajności, tylko bierzemy się do 
pracy. Często wystarczy wyłączyć emula u użytkowników sieci klienta, ale 
czasami trzeba poprawić nasz soft.

Pozdrawiam

-- 
Grzegorz Gruza
Odpowiadając usuń "spamerom_nie." z adresu!!!

Grzesiek G. napisał(a):
> Miałem do wykonania program walidujący i 
> importujący plik csv do bazy danych. Wyjściem z nieudanej walidacji był 
> raport błędów. Program był zrobiony tak, że przetwarzał plik do 
> struktury obiektowej, którą obrabiał i zapisywał w bazie. Plik był 
> poprawny, jeśli dawał się przekształcić do struktury obiektowej.
> 
> Niestety, rzeczywiste pliki okazały się fatalne. Tworzyło je pare osób w 
>  MS Office i różnych Open Officach, także walidacja stała się ważna. Co 
> gorsza za długo trwała (kilka minut), co bardzo złościło klienta. Była 
> napisana poczętkowo w stylu:
> try
> {
>     zmienna = decimal.Parse(napis);
>     ...
> }
> catch(InvalidFormatException exc)
> {
>     logger.log("Nie można skonwertować ...);
> }
> 
> została przepisana na:
> if(decimal.TryParse(napis)
> {
>     zmienna = decimal.Parse(Napis);
> }
> else
> {
>     logger.log("Nie można skonwertować ...);
> }
> Czas wykonania walidacji skrócił się do kilkudziesięciu sekund.

No to rzeczywiście obsługa wyjątków stanowiła wąskie gardło...
Poznanie tego przypadku było dla mnie ciekawym doświadczeniem.

--
Przemysław Pokrywka