🚀 go-pugleaf

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