🚀 go-pugleaf

Użytkownik "Michał Zaborowski" napisał w wiadomości ...
> Załóżmy, że otwieram plik, czytam i przy okazji coś tam sobie dziergam.
> Duży blok może mieć sens np. ze względów wydajnościowych. Przeglądam
> plik, wybierając co potrzebniejsze kąski, zamiast wszystko wywlekać do
> ramu. No i teraz może mi się to wywalić na kilka sposobów, więc daję
> kilka exceptów - na różne okazje. Problemem jest zamykanie pliku. Mogę
> dać na koniec, po exceptach, ale to jest słaby pomysł. Jak gdzieś dam
> re-raise... Czyli powinienem wwalić zwalnianie do wszystkich sekcji
> except. Można by dać final i tam sprawdzić, czy uchwyt nie jest null i
> wtedy zwolnić. Wiem doskonały przykład to nie jest, ale mam nadzieję,
> że udało mi się pokazać o co chodzi...

No chyba nie do końca. Jeśli główny blok przetwarzania danych
ujmiesz w try [blok] finally end, to niezależnie od tego, czy w bloku
wystąpi wyjątek i będziesz go propagował wyżej, czy też nie, to
sekcja zawarta między finally i end zawsze się wykona, więc
wystarczy, jak zamykanie pliku tylko tam umieścisz.

A tak w ogólę, to dziwię się, że używanie try finally end nadal sprawia problemy.
Przecież taki blok stosuje się de-facto mechnicznie:
1. Jeśli przed try jest Open, to po finally musi być Close
2. Jeśli przed try jest Create, to po finally musi być Free (Destroy)
3. Jeśli przed try jest Lock := True, to po finally musi być Lock := False;
i wszystkie inne tego typu przypadki.

Przy analizie bloku try finally end jest właściwie bez znaczenia, jaki kod znajduje się
między try, a finally. Ważne jest tylko to, że skoro wykonało się to, co jest przed try,
to zawsze musi wykonać się to, co jest między finally i end. Zapewnia to dalsze
"poprawne" działanie programu, niezależnie od tego, jakie wyjątki wystąpią w [blok].

-- 
pozdrowienia
Krzysztof Szyszka, X-Files Software
Developer of X-Files Components
Borland/CodeGear/Embarcadero Technology Partner
_________________________________________
Website: http://www.x-files.pl/  E-mail: news@x-files.pl