ich habe hier ein ziemlich doofes Problem. Im Prinzip lässt es sich auf folgendes Konstrukt runterbrechen:

class ScopedTransaction 
{
   DatabaseDAC* db_;
public:
   ScopedTransaction ( DatabaseDAC* db ) : db_( db )
   {
      assert( db_ );
      begin();
   }

   ~ScopedTransaction ()
   {
      rollback();
   }

   void begin()
   {
      if( db_->connected() ) db_->StartTransaction();
   }

   void commit()
   {
      if( db_->connected() ) db_->Commit();
   }

   void rollback()
   {
      if( db_->connected() ) db_->Rollback();
   }
};

void func( DatabaseDAC* db )
{
   try
   {
      ScopedTransaction ST( db );

      // SQL Zeugs hier
      g.commit();
   }
   catch( runtime_error& rte )
   {
   }
}

Wenn in der Funktion func innerhalb des try-catch-Blocks eine Exception auftritt wird vor dem Sprung in den Exception Handler der Destruktor von ScopedTransaction aufgerufen. Der wirft selbst wiederum eine Exception und läuft dadurch in unendliche Rekursion und schließlich in einen Stack Überlauf.
Das Problem tritt auf, wenn innerhalb der Transaktion die Verbindung zur db verloren geht. Eins der SQL Statements schlägt fehl und wirft eine Exception. Dann werden alle Variablen im try-catch Block zerstört, was zur Folge hat, dass im Destruktor von ScopedTransaction ein Rollback ausgeführt werden soll. Dummerweise liefert db_->connected() noch true zurück, sodass erneut eine Exception geworfen wird und zu dem Stack Overflow führt.
Wie kriegt man sowas in den Griff?

Herb Sutter schlägt vor, die Exception innerhalb des Destruktor abzufangen.

~ScopedTransaction ()
   {
      try {
         rollback();
      } catch(...) {
      }
   }

von uncaught_exception rät er ab.

Gruß
Werner