🚀 go-pugleaf

2006-03-28 08:44:08
Przemek Pokrywka <adres@zastrzezony.com> wrote in message
<e09c3r$lg3$1@news.onet.pl>

> Witam,
> 
> 
> Mam system, zawierający m.in. klasy:
> 
> class Person
>  getAge : int
> 
> class PersonFinder
>  find(name : string) : Person
> 
> 
> Metoda find klasy PersonFinder jest wywoływana bardzo często w 
różnych 
> sytuacjach, z kodu pisanego przez różnych autorów. Zdarza się, że 
kod 
> korzystający z tej metody kolekcjonuje zwracane przez nią obiekty 
Person 
> na wypadek potrzeby ich przyszłego użycia.
> W tej chwili, gdy metoda nie odnajdzie osoby o zadanym nazwisku, 
zwraca 
> wartość null.
> 
> 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).
> 
> Zapraszam do podzielenia się swoimi uwagami
Ja osobiœcie projektuję w takiej sytuacji dwie metody:
findSole(name : string) : Person, i
find(name : string) : PersonList
Ta pierwsza jest wywoływana kiedy z kontekstu businessowego wynika że 
na pewno istnieje dokładnie jedna taka osoba (np. name jest unikalne 
i zostało zwrócone przez innš metodę). Jeżeli taka osoba nie może 
zostać odnaleziona lub jest ich więcej niż jedna - findSole() rzuca 
wyjštek bo œwiadczy to o jakimœ wewnętrznym błędzie w aplikacji.
Ta druga zwraca po prostu listę spełniajšcej zadane kryteria. Jeżeli 
takich osób nie ma to lista jest pusta.

> 
> 
> Przemysław Pokrywka

-- 
Piotr Jachowicz

"Piotr Jachowicz" <piotr.jachowicz@ericpol.pl> wrote:

> Ja osobiście projektuję w takiej sytuacji dwie metody:
> findSole(name : string) : Person, i
> find(name : string) : PersonList
> Ta pierwsza jest wywoływana kiedy z kontekstu businessowego wynika że
> na pewno istnieje dokładnie jedna taka osoba (np. name jest unikalne
> i zostało zwrócone przez inną metodę). Jeżeli taka osoba nie może
> zostać odnaleziona lub jest ich więcej niż jedna - findSole() rzuca
> wyjątek bo świadczy to o jakimś wewnętrznym błędzie w aplikacji.
> Ta druga zwraca po prostu listę spełniającej zadane kryteria. Jeżeli
> takich osób nie ma to lista jest pusta.

Robie _dokladnie_ (a raczej bardzo podobnie :) jak Ty.
Z mala zmiana w nazewnictwie;

Po prostu:
 get(name : string) : Person
albo

 getByName(name : string) : Person

AK

Adam Karpierz napisał(a):
> "Piotr Jachowicz" <piotr.jachowicz@ericpol.pl> wrote:
> 
>>Ja osobi�cie projektuję w takiej sytuacji dwie metody:
>>findSole(name : string) : Person, i
>>find(name : string) : PersonList
> 
> Robie _dokladnie_ (a raczej bardzo podobnie :) jak Ty.
> Z mala zmiana w nazewnictwie;
> 
> Po prostu:
>  get(name : string) : Person
> albo
> 
>  getByName(name : string) : Person

Chciałbym zwrócić uwagę, że getByName zwraca pojedynczą osobę, a nie 
listę, jak u pana Piotra. Czy słusznie podejrzewam w tym kontekście, że 
jedna z nich wyrzuca wyjątek?

Przemysław Pokrywka

"Adam Karpierz" <karpierz@NOOOOSPAAAAMpython.pl> wrote:

> > Ja osobiœcie projektuję w takiej sytuacji dwie metody:
> > findSole(name : string) : Person, i
> > find(name : string) : PersonList

> Po prostu:
>  get(name : string) : Person
> albo
>
>  getByName(name : string) : Person

Ja pisze "find" i "search" :-)


mp

Przemek Pokrywka <adres@zastrzezony.com> napisał(a): 

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

uch, uch! a może to jednak powinno być tak?

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

Jest subtelna roznica pomiedzy tymi dwoma przykładami.

A tak w ogole to wiekszosc moich znajomych nie lubi checked exceptions, i jak
sie da to zawijaja je w unchecked. A znam nawet takich, co uwazaja ze w ogole
nie powinno sie we wlasnym kodzie wprowadzac wyjatkow, tylko raczej zwracac
wartosci oznaczajace bledy - i potrafia to przekonujaco uzasadniac (a ja
niekoniecznie).

pozdrawiam,
-MS

-- 
Wysłano z serwisu Usenet w portalu Gazeta.pl -> http://www.gazeta.pl/usenet/

Marcin Stefaniak napisał(a):
> Przemek Pokrywka <adres@zastrzezony.com> napisał(a): 
> 
> 
>>czytelniejsze jest:
>>try {
>>	Person person = find("nemo");
>>	process(person);
>>catch (PersonNotFoundException e) {
>>	noPersonFoundCase();
>>}
> 
> 
> uch, uch! a może to jednak powinno być tak?
> 
> Person person;
> try {
>   person = find("nemo");
> } catch (PersonNotFoundException e) {
>   noPersonFoundCase();
> }
> process(person);
> 
> Jest subtelna roznica pomiedzy tymi dwoma przykładami.

Owszem, zauważam różnicę, jednak wywołanie metody process celowo 
pozostawiłem wewnątrz klauzuli try, zakładając, że process jest w stanie 
prawidłowo obsłużyć tylko przypadek, gdy przekazany Person nie jest nullem.

> A tak w ogole to wiekszosc moich znajomych nie lubi checked exceptions, i jak
> sie da to zawijaja je w unchecked. 

Zdążyłem już zaznajomić się z trendem nieużywania checked exceptions - 
ze znanych postaci reprezentuje go m.in. Bruce Eckel. Sam poniekąd 
rozumiem jego argumenty, bo prawidłowe używanie checked exceptions 
wprowadza więcej pracy, co źle odbija się na tempie rozwoju aplikacji w 
jej wczesnym stadium. Jednak gdy aplikacja się rozrasta, checked 
exceptions pozwalają moim zdaniem na lepsze ogarnięcie tego uniwersum 
błędów, które może w niej wystąpić. Nie jestem jednak zwolennikiem 
używania ich zawsze i wszędzie.

 > A znam nawet takich, co uwazaja ze w ogole
> nie powinno sie we wlasnym kodzie wprowadzac wyjatkow, tylko raczej zwracac
> wartosci oznaczajace bledy - i potrafia to przekonujaco uzasadniac (a ja
> niekoniecznie).

Ja nie potrafię tego w żaden sposób wytłumaczyć, kody błędów to dla mnie 
śmieszny archaizm :)


--
Pozdrawiam,
Przemysław Pokrywka

Przemek Pokrywka <adres@zastrzezony.com> napisał(a): 

>  > A znam nawet takich, co uwazaja ze w ogole
> > nie powinno sie we wlasnym kodzie wprowadzac wyjatkow, tylko raczej zwracac
> > wartosci oznaczajace bledy - i potrafia to przekonujaco uzasadniac (a ja
> > niekoniecznie).
> 
> Ja nie potrafię tego w żaden sposób wytłumaczyć, kody błędów to dla mnie 
> śmieszny archaizm :)

OK. Filozofia jest mniej wiecej taka :-)

Nasz kod to taki, który możemy swobodnie zmieniać, poprawiać. Zatem jest on
poprawny, albo możemy go poprawić, jak się okaże że jest gdzieś bug. W każdym
razie, można z nim dążyć do doskonałości. Czyli sytuacje błędne nie mają się w
nim pojawiać. Każdy runtime exception oznacza bug w kodzie i prowadzi do
szybkiego bugfixa. Zatem, jeśli coś jest przewidywalnym i zaprojektownym
"błędem", to jest raczej wynikiem działania pewnej funkcji niż wyjątkiem - nie
chcemy ani nie potrzebujemy znać jego stacktrace'u, co jest główną różnicą
między wyjątkiem a zwracaniem kodu błędu (są też inne różnice, ale mniej ważne).

-MS

-- 
Wysłano z serwisu Usenet w portalu Gazeta.pl -> http://www.gazeta.pl/usenet/

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

Rozwazmy prosta gre, po zakonczeniu ktorej uzytkownik moze wpisac sie na
liste najlepszych graczy (jezeli chce). Lista najlepszych graczy trzymana
jest w pliku wyniki.txt. Plik ten tworzony jest przy pierwszej checi zapisu
wyniku gry.  Po odpaleniu gry w centralnej czesci ekranu pojawiaja sie
wyniki najlepszych graczy - o ile istnieje plik wyniki.txt , w przeciwnym
wypadku wyswietlane jest logo gry.

Ja bym zrobil tak:
File wyniki = new File("wyniki.txt");
if (wyniki.exists() ) { wyswietl wyniki }
else { wyswietl logo }

Oczywiscie kod, ktory czyta plik jest jeszcze obudowany w try, gdyby
zaistniala jakas sytuacja wyjatkowa.

Rozumiem, ze koledzy Przemek, Marcin i Michal w IF'a by sie nie bawili tylko
zalatwiliby wszystko CATCH'em.

Adam

Adam Przybyłek napisał:
> Ja bym zrobil tak:
> File wyniki = new File("wyniki.txt");
> if (wyniki.exists() ) { wyswietl wyniki }
> else { wyswietl logo }
> 
> Oczywiscie kod, ktory czyta plik jest jeszcze obudowany w try, gdyby
> zaistniala jakas sytuacja wyjatkowa.
> 
> Rozumiem, ze koledzy Przemek, Marcin i Michal w IF'a by sie nie bawili tylko
> zalatwiliby wszystko CATCH'em.

Ja z całą pewnością. Pomijając zasadę, że wyjątki i testy logiczne w 
danej metodzie powinny znajdować się na jednym poziomie abstrakcji (a 
więc kod  dotyczący plików powinien zostać ukryty za logicznymi 
warunkami wyświetlenia jednej lub drugiej planszy) kod mógłby wyglądać w 
sposób zbliżony do następującego:

Plansza plansza;
try {
    plansza = odczytajWyniki();
} catch (IOException) {
    plansza = logo;
}
wyswietl(plansza);


--
Przemysław Pokrywka

Jeszcze jeden przyklad na zastosowanie wyjatkow.

Wezmy na przyklad klase Stack z Javy. Metoda pop() rzuci wyjatek
EmptyStackException, jezeli wywolamy ja na rzecz pustego stosu.
Klasa ta ma takze metode empty() testujaca czy stos nie jest pusty.

Rozwazmy dwa przypadki:
1) Wiemy, ze stos nie jest pusty
2) Nie wiemy, czy stos jest pusty

Jezeli chcemy zdjac element ze stosu to:
-w przypadku 1) wewnatrz try wolamy pop()
-w przypadku 2) najpierw wolamy metode empty() i dopiero jak sie upewnimy ze
jest cos na stosie to metode pop()

Adam

Adam Przybyłek napisał(a):
> Jeszcze jeden przyklad na zastosowanie wyjatkow.
> 
> Wezmy na przyklad klase Stack z Javy. Metoda pop() rzuci wyjatek
> EmptyStackException, jezeli wywolamy ja na rzecz pustego stosu.
> Klasa ta ma takze metode empty() testujaca czy stos nie jest pusty.
> 
> Rozwazmy dwa przypadki:
> 1) Wiemy, ze stos nie jest pusty
> 2) Nie wiemy, czy stos jest pusty
> 
> Jezeli chcemy zdjac element ze stosu to:
> -w przypadku 1) wewnatrz try wolamy pop()
> -w przypadku 2) najpierw wolamy metode empty() i dopiero jak sie upewnimy ze
> jest cos na stosie to metode pop()

Dobrze, weźmy taki przykład :-)

ad 1.
Skoro wiemy, to po co try? Chciał chyba kolega powiedzieć "wydaje nam 
się" lub "zakładamy" - wtedy użycie try jest uzasadnione.

ad 2.
czyli:
if ( ! stack.empty()) {
	Object result = stack.pop();
}
co jest konstrukcją ewidentnie błędną, bo kto zagwarantuje, że między 
wywołaniem empty() a pop() stan stosu nie ulegnie zmianie? (np. wskutek 
działania innego wątku)
Użycie pop() wewnątrz try jest tu znacznie bardziej uzasadnione.

Jest też uzasadnienie użycia try/catch, biorące pod uwagę intuicyjność 
zapisu kodu programu. Otóż niezależnie od naszej wiedzy o stanie stosu, 
chcemy z niego zdjąć element, żeby coś z nim zrobić ("plan A"). Jeśli z 
jakiś powodów uzyskanie tego elementu nie będzie możliwe, przechodzimy 
do realizacji "planu B". Trzeba jednak podkreślić, że naszą intencją 
jest pomyślne przeprowadzenie "planu A", a "plan B" jest tylko naszym 
ubezpieczeniem się na wypadek sytuacji awaryjnej. Nikomu nie powinno 
mieszać się, który plan jest podstawowy, a który awaryjny.

Dlatego znacznie lepiej będzie zapisać plan podstawowy w bloku try, a 
plan awaryjny w bloku catch, gdzie jest jego naturalne miejsce i gdzie 
nikt nie podejrzewa, że jest on planem podstawowym. Co więcej, nazwa 
wyjątku w klauzuli catch wyraźnie komunikuje, co może być przyczyną 
przejścia do "planu B". Uczciwie przyznam przy tym, że aby to podejście 
dobrze działało, programista piszący ten kod powinien przestrzegać 
zasady o posługiwaniu się wyjątkami i wywołaniami metod o tym samym 
poziomie abstrakcji, co kod rozpatrywanej metody (tak, aby obliczanie 
pensji pracownika nie mieszało się z operacjami na plikach i bazie 
danych). Zasada ta obowiązuje jednak także w wypadku posługiwania się 
instrukcją if.

try {
	Object result = stack.pop();
	// "plan A"
} catch (EmptyStackException stackWasEmpty) {
	// "plan B"
}
Instrukcja warunkowa if z kolei nie wyróżnia żadnej ze swych gałęzi i 
tylko, gdy programista zachowuje odpowiednią dyscyplinę (umieszcza 
przypadki pozytywne w pierwszej gałęzi if'a), z kodu daje się wyczytać, 
który scenariusz jest tym podstawowym.

Wywoływanie metody empty() ma dla mnie sens w sytuacjach, gdy programowi 
wcale w danej chwili nie zależy na zdejmowaniu jakichkolwiek elementów 
ze stosu, a jedynie na wyświetlenie jakiejś informacji użytkownikowi lub 
zakomunikowanie tego faktu innemu systemowi, który na tej podstawie 
podejmie jakieś decyzje we własnym zakresie. Ponieważ programowi nie 
zależy na posługiwaniu sie elementami ze stosu próby pobierania elementu 
i łapanie wyjątku byłyby w tej sytuacji zupełnie zbędnymi operacjami.

Ogólniej, sprawdzenia typu empty() mogą mieć też sens w sytuacjach, gdy 
są one mało kosztowne, a pozwalają na uniknięcie operacji o bardzo dużym 
koszcie (jak np. sprawdzenie objętości maila przed wysłaniem go do 
adresata, którego system pocztowy nie toleruje wiadomości 
przekraczających określoną wielkość). Jest to jednak tylko pewnego 
rodzaju foreign method, która przyspiesza jedynie wystąpienie 
ewentualnej sytuacji wyjątkowej, a nie jest istotnym punktem decyzyjnym 
logiki programu.

Pewnie zastosowanie sprawdzeń tego typu dałoby się jeszcze uzasadnić na 
innych przykładach, ale na pewno nie na podanym powyżej.

--
Przemysław Pokrywka

Przemek Pokrywka <adres@zastrzezony.com> writes:

> if ( ! stack.empty()) {
> 	Object result = stack.pop();
> }
> co jest konstrukcją ewidentnie błędną, bo kto zagwarantuje, że między
> wywołaniem empty() a pop() stan stosu nie ulegnie zmianie? (np.
> wskutek działania innego wątku)

Jeśli ten stos nie przewiduje używania w wielu wątkach naraz
(co w większości języków wymaga jawnej synchronizacji), to użycie go
w wielu wątkach bez synchronizacji i tak jest błędne, więc silenie się
na unikanie wyjątku jest bezcelowe.

> Jeśli z jakiś powodów uzyskanie tego elementu nie będzie możliwe,
> przechodzimy do realizacji "planu B". Trzeba jednak podkreślić, że
> naszą intencją jest pomyślne przeprowadzenie "planu A", a "plan B"
> jest tylko naszym ubezpieczeniem się na wypadek sytuacji awaryjnej.

To zależy od konkretnego problemu, może tak być albo może nie być.
Opis problemu był dość abstrakcyjny i tego nie rozstrzygał.

> Dlatego znacznie lepiej będzie zapisać plan podstawowy w bloku try,
> a plan awaryjny w bloku catch, gdzie jest jego naturalne miejsce
> i gdzie nikt nie podejrzewa, że jest on planem podstawowym.

Używanie tradycyjnego 'try' w tego typu sytuacjach ma taką wadę, że
łapane są również wyjątki w trakcie przetwarzania elementu usuniętego
ze stosu. Jeśli w trakcie tych obliczeń zostało wykonane jakieś pop()
na zupełnie innym stosie, który okazał się pusty, to prawdopodobnie
powrót do tego miejsca i wykonanie kodu przeznaczonego dla sytuacji
braku elementu na tym stosie jest błędem, zwykle polegającym na
zamaskowaniu innego błędu.

Winę ponosi składnia i semantyka 'try' w większości języków: brakuje
możliwości określenia kodu, który należy wykonać, kiedy nie było
wyjątku, ale już bez łapania tutaj wyjątków z tego kodu. Ten kod
powinien mieć dostęp do zmiennych zdefiniowanych w głównym ciele 'try'.

Można to zasymulować tradycyjnym 'try': w głównym ciele zmaterializować
w zmiennych lokalnych informację o niewystąpieniu wyjątku, w kodzie
łapiącym wyjątki zapisać przeciwną informację, a na zewnątrz 'try'
sprawdzić, czy ten 'try' skończył się obsłużeniem wyjątku czy nie.

To jest jednak mniej wygodne niż włożenie wszystkiego do 'try'.

Pewnie większość programistów nie zdaje sobie sprawy, że po cichu
przyjmuje założenie, że ten kod przesunięty do środka 'try' nie
skończy się łapanym tutaj wyjątkiem, i tworzy kod, który jest mniej
"robust" albo zgoła błędny.

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

>Przemek Pokrywka <adres@zastrzezony.com> writes:
>
>> if ( ! stack.empty()) {
>>  Object result = stack.pop();
>> }
>> co jest konstrukcją ewidentnie błędną, bo kto zagwarantuje, że między
>> wywołaniem empty() a pop() stan stosu nie ulegnie zmianie? (np.
>> wskutek działania innego wątku)
>
>Jeśli ten stos nie przewiduje używania w wielu wątkach naraz
>(co w większości języków wymaga jawnej synchronizacji), to użycie go
>w wielu wątkach bez synchronizacji i tak jest błędne, więc silenie się
>na unikanie wyjątku jest bezcelowe.
>
>> Jeśli z jakiś powodów uzyskanie tego elementu nie będzie możliwe,
>> przechodzimy do realizacji "planu B". Trzeba jednak podkreślić, że
>> naszą intencją jest pomyślne przeprowadzenie "planu A", a "plan B"
>> jest tylko naszym ubezpieczeniem się na wypadek sytuacji awaryjnej.
>
>To zależy od konkretnego problemu, może tak być albo może nie być.
>Opis problemu był dość abstrakcyjny i tego nie rozstrzygał.
>
>> Dlatego znacznie lepiej będzie zapisać plan podstawowy w bloku try,
>> a plan awaryjny w bloku catch, gdzie jest jego naturalne miejsce
>> i gdzie nikt nie podejrzewa, że jest on planem podstawowym.
>
>Używanie tradycyjnego 'try' w tego typu sytuacjach ma taką wadę, że
>łapane są również wyjątki w trakcie przetwarzania elementu usuniętego
>ze stosu. Jeśli w trakcie tych obliczeń zostało wykonane jakieś pop()
>na zupełnie innym stosie, który okazał się pusty, to prawdopodobnie
>powrót do tego miejsca i wykonanie kodu przeznaczonego dla sytuacji
>braku elementu na tym stosie jest błędem, zwykle polegającym na
>zamaskowaniu innego błędu.
 
To jest problem tylko w przypadku unchecked exception. W przypadku checked
exception hipotetyczny kod obslugujacy "przetwarzanie elementu usuniętego
ze stosu" zwykle jest rozbity na osobne metody i obsluga bledu zwiazanego z
zagniezdzonym pop() jest gdzie indziej juz napisana. Problem pozostaje, jesli
sie ten zagniezdzony pop() jest w tej samej metodzie w tym samym try. No ale
taka praktyka nalezy do kategorii zaciemniania kodu.


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

W zupełności zgadzam się z uwagami o synchronizacji, jak również o 
niebezpieczeństwie nieświadomego wyłapywania nieprzewidzianych wyjątków, 
gdy są one tego samego typu. Jednak myślę, że rozwiązaniem lepszym od 
ustawiania i sprawdzania flag o wystąpieniu wyjątku jest po prostu 
zagnieżdżanie instrukcji try jedna w drugiej (najlepiej już w osobnej 
metodzie, by nie mnożyć wcięć utrudniających szybkie ogarnięcie kodu).
W jakikolwiek sposób jednak by sobie nie radzić z tym problemem, 
kluczową nierozwiązaną kwestią pozostanie samo pamiętanie o możliwości 
wystąpienia takiej sytuacji. Tego faktycznie bez rozszerzonej składni 
'try' się nie obejdzie.

>>Jeśli z jakiś powodów uzyskanie tego elementu nie będzie możliwe,
>>przechodzimy do realizacji "planu B". Trzeba jednak podkreślić, że
>>naszą intencją jest pomyślne przeprowadzenie "planu A", a "plan B"
>>jest tylko naszym ubezpieczeniem się na wypadek sytuacji awaryjnej.
> 
> To zależy od konkretnego problemu, może tak być albo może nie być.
> Opis problemu był dość abstrakcyjny i tego nie rozstrzygał.

Dosyć jednak precyzyjny, by wskazać główną intencję programu - cytuję:
"Jezeli chcemy zdjac element ze stosu".

--
Pozdrawiam,
Przemysław Pokrywka

Aleksander Galicki napisał(a):
>>Używanie tradycyjnego 'try' w tego typu sytuacjach ma taką wadę, że
>>łapane są również wyjątki w trakcie przetwarzania elementu usuniętego
>>ze stosu. Jeśli w trakcie tych obliczeń zostało wykonane jakieś pop()
>>na zupełnie innym stosie, który okazał się pusty, to prawdopodobnie
>>powrót do tego miejsca i wykonanie kodu przeznaczonego dla sytuacji
>>braku elementu na tym stosie jest błędem, zwykle polegającym na
>>zamaskowaniu innego błędu.
> 
>  
> To jest problem tylko w przypadku unchecked exception. W przypadku checked
> exception hipotetyczny kod obslugujacy "przetwarzanie elementu usuniętego
> ze stosu" zwykle jest rozbity na osobne metody i obsluga bledu zwiazanego z
> zagniezdzonym pop() jest gdzie indziej juz napisana. 

Zwykle jest, ale nie zawsze. A nawet jeśli, to metody te równie dobrze 
mogą obsłużyć ten checked exception, jak i go po prostu wyrzucić, 
rezerwując sobie tę możliwość w swoich sygnaturach w klauzuli throws.

Problem nie dotyczy więc wyłącznie unchecked exceptions, lecz w ich 
wypadku przeoczenie właściwej obsługi błędu jest jeszcze łatwiejsze.

> Problem pozostaje, jesli
> sie ten zagniezdzony pop() jest w tej samej metodzie w tym samym try. No ale
> taka praktyka nalezy do kategorii zaciemniania kodu.

Problem pozostaje, choć taki przypadek nawet niekoniecznie musi się dać 
zaklasyfikować jako "zaciemniacz" - mam na myśli sytuację, gdy 
zagnieżdżony pop() stanowi większość, lub też całość logiki pozytywnego 
scenariusza programu. Jeśli tylko należy do właściwego poziomu 
abstrakcji (operacje na kolekcjach), to nie widzę przeciwskazań, żeby go 
tam umieszczać bez obaw o zaciemnienie kodu.

--
Pozdrawiam,
Przemysław Pokrywka