Nagyjából értem, tehát, ha exception közben a destructor is exceptiont-dob, akkor std::terminate() lesz a vége, azaz crash, mert nem tudnak lefutni a vészleálló mechanizmusok... Na most, az, hogy a destructor lehetőleg ne dobáljon exceptiont, az rendben van, de mi van, ha "a nyelv" (azaz valami built-in mechanizmus) dob alatta egyet? Olyan lehetséges? Pl. OoM esetén sem maga a konstruktor dobja, mert az kipurcant, hanem valamelyik mechanizmusa a C++-nak.
Egyetértek. Ahogy mondtam is korábban, a saját dolgaimban nem használok exceptionokat, mert igaziból nem szeretem, ill., nincs rá szükségem. De az out_of_mem kezelése kivételt képez, szóval ilyesmi durva esetekre szerintem jó eszköz lehet. Én teljes mértékben a visszatérési érték alapú hibakezelést preferálom, amivel tudom, hogy sokan nem értenek egyet, nem ez az elfogadott C++ körökben. De még senki se tudott meggyőzni arról, hogy az exceptionok jók az általános hibakezelésre (pedig amúgy nyitott lennék rá, csak a felhozott érveimre, kérdéseimre nem tudnak megnyugtató válaszokat adni). Szerintem több hátránya van, mint előnye. És ugye azért vannak az újabb nyelvek designerei között is olyanok, akik hasonlóan gondolkodhatnak. Se a go-ban, se a Rustban nincs az a klasszikus exceptionkezelés.
Na, most sikerült teljesen összezavarnod... :)))
Eddig arról győzködtél, hogy az exception-ök gyorsabban fognak működni, mint ha mindent elágazásokkal lekezelünk (már, ha nincs tényleges throw) és azt írtad, hogy felmondanál, ha neked egyesével kellene minden deallokációt és egyéb vacakot megírnod, ahelyett, hogy az exception lekezelné.
Rendben, hogy OoM-ról beszéltünk főleg, de kivételt bármi dobhat, ami után fel kell minden túrót szabadítani; socket error, file error, whatever error... Vagy C++-ban erre van valami egyéb megoldás is?