<f...@g...skasuj-to.pl> wrote:

> jak wspomnialem mz wykorzystanie wyjatkow by wylaczyc na stale jakas
> funkcje/galaz z ktorej polecial jakis niezidentyfikowany blad moze
> byc moze miec ew pewien sens - (poki co jedyne ew sensowne dzialanie
> jakiemi sie z tym kojarzy) - ale nie pisze poki co programow
> ktore by tego wymagaly a wolalbym kiedys przemyslec obsluge bledow w
> szerszy i ogolnijszy sposob

Ukrywanie błędów to ślepa uliczka. Tak długo, jak nie masz pewności, co
właściwie się stało, próba kontrolowanego kontynuowania programu może
być ryzykowna. Chociażby dlatego że nie wiesz w jakim stanie jest heap,
w końcu poszedł wyjątek = coś poszło nie tak jak przewidziano.

M.in. dlatego stosowanie catchall jest przez wielu uznawane za złą praktykę.

Osobna sprawa to catch własnego wyjątku - ja często w miejscach, w których
zakładam, że coś powinno być tak a nie inaczej, daję dla pewności coś ala
assert - ale własny, zawsze kompilowany, a nie biblioteczny (który rozwijany
jest tylko w wersji debugowej). Makro sprawdza warunek i jak jest niezgodny,
to rzuca wyjątek z określoną treścią, np:

int rs = funkcja();
Assert(rs == 3, "%d", rs);

switch (a)
{
case ...:
break;
default:
Assert(false, "%d", a);
}

Wtedy funkcja łapiąca wyjątek może wypisać komunikat i wyjść, a main wtedy
zakończy program (dbam o to żeby miejsce wyjścia z programu było tylko
jedno).

> nie wiem po co niektore pola (np edi esi ebx, czy to potrzeba zachowania
> czesci kontekstu funkcji z catch? ani co to jest j_ret)

Jak chcesz programować wysokopoziomowo to musisz nauczyć się myśleć
wysokopoziomowo. Rejestry zostaw kompilatorowi.

--
Gof