class Test{
public:
  Test(void){}
  ~Test(void){throw int(10);}
};

void func(void){
  Test t;
  throw "Error";
}

int main(int argc, char* argv[]){
  try{
    func();
  }catch(int i){
    printf("int\n");
  }catch(char *s){
    printf("char*\n");
  }
  return 0;
}

Hat jemand eine Idee, was in diesem Falle am sinnvollsten passieren sollte, oder wie andere Compiler mit dieser heiklen Situation umgehen?

Grüße,
mm

Hm, ok, das sehe ich ein, nur es kann ja sein, dass die Exception im Destruktor nicht explizit von mir geworfen wird. Wenn ich im Destruktor irgend ein dynamisches Listen-Objekt benutze, welches eine "OutOfRange"-Exception wirft, oder es zu einer "StackOverflow"-Exception oder Ähnlichem kommt, dann würde das Problem ja ohne mein Zutun entstehen.
Das würde dann ja bedeuten, dass mein Programm trotz Exception-Handling immer noch unkontrolliert terminieren kann.

Das bedeutet, dass du in Destruktoren solche Funktionen nicht aufrufen darfst oder sonst diese Exceptions fangen musst, bevor sie den Destruktor verlassen. Jede Technik, die zu Exceptionsicherheit führt, beruht notwendig auf einer Reihe von Operationen, die garantiert keine Exception auslösen.

class Test{
public:
  Test(void){}
  ~Test(void){try{throw "null problemo";}catch(const char*){}}
};

void func(void){
  Test t;
  throw "Error";
}

int main(int argc, char* argv[]){
  try{
    func();
  }catch(int i){
    printf("int\n");
  }catch(const char *s){
    printf("const char*\n");
  }
  return 0;
}

"Falls während des Stack-Unwindings eine weitere Exception geworfen wird" ist also nicht ganz präzise, korrekter ist es, zu sagen, falls eine Exception einen Destruktor verlässt, während der Stack aufgerollt wird.

besser ist es, eine eigene funktion à la close zu implementieren, und diese im destruktor dann so aufzurufen:

class Foo
{
public:
  ~Foo ()
  {
    try
    {
      close();
    }
    catch(...) { }
  }
};

siehe auch http://www.gotw.ca/gotw/047.htm

"Falls während des Stack-Unwindings eine weitere Exception geworfen wird" ist also nicht ganz präzise, korrekter ist es, zu sagen, falls eine Exception einen Destruktor verlässt, während der Stack aufgerollt wird.

danke für die klarstellung, da wollte ich gerade nochmal nachfragen.

Aber ich habe auch mal einen Blick über den Tellerrand von C++ gewagt und geschaut wie es zB bei C# aussieht:
* Da C# über einen Garbage-Collector verfügt ist nicht genau bestimmt, wann die Destruktoren aufgerufen werden (ja, die gibts auch dort), daher werden nicht behandelte Exceptions in ihnen einfach verworfen und führen nicht zum Terminieren des Programms.
* Beim Stack-Unwinding kann mit Hilfe eines try{...}finally{...} Blocks zusätzlicher Code ausgeführt werden. Tritt dort eine weitere Exception auf, wird die Alte einfach überschrieben.

Also auch keine echte Patentlösung, aber ich finde, dass das finally-Konstrukt in C++ auch enthalten sein sollte.

Also auch keine echte Patentlösung, aber ich finde, dass das finally-Konstrukt in C++ auch enthalten sein sollte.

Ich finde, es ist aus gutem Grund nicht enthalten. Wenn man sich an den RAII-Grundsatz hält, steht sämtlicher Code, der beim Verlassen des Scopes aufgerufen werden soll, in irgendwelchen Destruktoren. Sowas ist in C# oder Java (eben wegen der unbestimmten Ausführung der Destruktoren) nicht möglich.

void func(void){
  TIniFile *ini = new TIniFile("file.ini");
  throwsExceptions();
  delete ini;
}

In diesem Falle ist man gezwungen die Fehlerbehandlung an dieser Stelle vorzunehmen, oder sich ein Wrapper-Objekt zu basteln, welches über einen Destruktor verfügt.

In diesem Falle ist man gezwungen die Fehlerbehandlung an dieser Stelle vorzunehmen, oder sich ein Wrapper-Objekt zu basteln, welches über einen Destruktor verfügt.

Genau dafür gibt's doch Smartpointer.

In diesem Falle ist man gezwungen die Fehlerbehandlung an dieser Stelle vorzunehmen, oder sich ein Wrapper-Objekt zu basteln, welches über einen Destruktor verfügt.

Hierfür gibt es in C++ bewährte Techniken, genannt Smartpointer. Deine Standardbibliothek bietet sogar einen einfachen an (auto_ptr, hat aber ein paar Nachteile), bessere gibt es in der Standarderweiterung TR1 (shared_ptr ist fast wie Garbage Collection), enthalten in boost, oder bei neueren GCCs auch frei Haus. Schau dazu mal in die Artikel-Abteilung, da gibt es was zu Smartpointern.

std::auto_ptr<TIniFile> ini( new TIniFile("file.ini") ); // oder std::tr1::shared_ptr
  ini->throwsExceptions();
  // nix :)