W dniu 2012-06-04 09:34, Maciej Sobczak pisze:

> Ja najchętniej korzystam z traksakcji z automatycznym rollbackiem,
> wyzwalanym przez destruktor. Wtedy opcja B jest kompletnie bez sensu

Czyli korzystasz ze wzorca projektowego RAII
(nazwa niezbyt trafna, ale tak już zostało).
Taką konstrukcję zastosujesz tylko w językach bez asynchronicznie
działającego garbage collectora, tzn. w takich, w których masz jasno
zdefiniowany moment odpalania konstruktora. W języku takim jak
Java czy C# nie robi się tego z pomocą destruktorów, tylko
ew. możesz walnąć (w C#) klauzulę 'using'.
(patrz
http://en.wikipedia.org/wiki/Resource_Acquisition_Is
_Initialization#Resource_management_without_RAII
).

Sugestia wyrzucenia begina przed try jest oczywiście niedoskonała,
ale jak najbardziej poprawna. W podanej w przykładzie konstrukcji
sekcja catch służy zasadniczo do obsługi rollbacka transakcji,
a nie wszelkich problemów zwiazanych z bazą danych. Jeśli chcemy
obsłużyć jakiś gruby problem z bazą, powodujacy, że nawet begin nie
wskakuje, to nic nie stoi na przeszkodzie by całość otoczyć
jeszcze jednym try-catchem, takim do obsługi błędów 'grubych'.

> (zły scope), natomiast obiekt zarządzający transakcją i tak nie zrobi
> żadnego rollbacka jeśli begin się nie powiodło, co powoduje, że opcja
> B jest jeszcze bardziej bez sensu a opcja A nie dość, że jest
> poprawna, to nawet da się zwykle zapisać prościej.
> Rozważania nt. A/B to rozwiązywanie problemów, których w ogóle nie
> powinno być ale niestety są, bo język programowania jest dziadowski.
> No właśnie - co to za język programowania?
Jeden z języków, w którym nie masz możliwości zastosowania wzorca RAII.

Wyobraź sobie, że zamiast transakcji masz tam operację otwarcia pliku,
zapisu do tego pliku i zamknięcia pliku. Przed try próbujesz
plik otworzyć do zapisu. Jeśli się to nie powiedzie, błąd 'gruby', wypad
z funkcji.
Dopiero, kiedy się powiedzie wchodzisz do try/catch/finally - i tu
np. zadaniem sekcji 'finally' jest posprzątanie deskryptora otwartego
pliku (close itp). Masz ściśle określone, wąskie zadanie związane
ze zwalnianiem jakiegoś zajętego zasobu. Jeśli zasób (plik, transakcja)
w ogóle nie został zajęty, to nie ma w ogóle sensu wchodzenie do
'finally', czy 'catcha' (catch ma za zadanie obsługę błędów
odczytu/zapisu do otwartego zasobu, a nie 'wszelkich możliwych').
Zauważ, że jeśli wrzucisz otwieranie po try, to potem w finally musisz
się zastanawiać, czy robić close, czy nie (dodatkowy if). A tego właśnie
chcemy uniknąć.