🚀 go-pugleaf

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/