gibt es in C++ auch eine Möglichkeit vom Compiler checken zu lassen,
ob alle Exceptions gecatcht werden? Oder nur bei bestimmten Compilern?
Ich verwende gcc unter KDevelop

Kann ich irgendwie den Methoden-Stack ausgeben lassen wie in Java?

Gruß,
CSpille

gibt es in C++ auch eine Möglichkeit vom Compiler checken zu lassen,
ob alle Exceptions gecatcht werden?

Imo dürfte sowas nicht möglich sein. Wenn du aber sichergehen willst, dass alle Exceptions gefangen werden, dann bau ein catch (...) in main ein.

CSpille schrieb:

Kann ich irgendwie den Methoden-Stack ausgeben lassen wie in Java?

Bin mir zwar nicht ganz sicher, was du mit Methoden-Stack meinst. Falls du damit den Call-Stack meinst, ja das geht. Allerdings nur mit einigen nachträglichen Eingriffen. Für bestehenden Code geht das nicht, zumindest nicht portabel.

Den Callstack kann man so auch nicht ausgeben, außer man ist in der Debug-Compilierung und man baut COmpiler-Spezifische printouts ein. Aber ist auch nicht das was du eigentlich willst.

Bedenke eines: C++ ist eine Compiler-Sprache! D.h. zur Laufzeit bekommst du keine Informationen, RTTI ist seeeeeeeeeeeeeehr mager und kann ja sogar abgeschaltet werden (was dich ja doch stutzig machen sollte).

Denk C++!

Kannst du mal erklaeren wie du an den Call-Stack kommst? Weisst du irgendwie an welcher Adresse der liegt, bzw. vor oder nach welchem Segment, sodass du dir die Adresse errechnen kannst?

Der Call-Stack "liegt" nirgendwo, zumindest aus C++ Sicht. Entweder bauen Compiler sich diesen selbst (zwecks Debugging) oder du machst das manuell. Ersteres ist allerdings nicht portabel. Es gibt zwar noch die Möglichkeit, den Stack Speicher durchzugehen, aber dies ist vielmehr ein indirekter Call-Stack, da dort lediglich Rücksprungadressen stehen.
Die einzige Möglichkeit einen relativ portablen Call-Stack zu implementieren, ist, diesen selbst zu integrieren. Dazu bastelst du dir eine Klasse, welche pro Funktion einmal instanziert wird. Welche Informationen du dort rein packst ist dir überlassen. Sinnvoll wäre zumindest der Name der Funktion. Die meisten C++ Compiler kennen C99, dh du kannst dann __func__ benutzen. Und selbst Compiler, die das nicht kennen, bieten dafür idR ein eigenes Makro bzw eine eigene Konstante an. Die erstellte Instanz wird dann in einen globalen Stack-Container gepusht und mit dem dtor wieder gepopt. Der einzige Nachteil an dieser ganzen Geschichte ist, dass du prkatisch in jeder Funktion am Beginn die Instanzierung vornehmen musst. Zwar kann man das mit 'nem Makro noch etwas anwenderfreundlicher verpacken, hinschreiben muss man es aber trotzdem.

Hilft std::uncaught_exception nur bei von std::exception abgeleiteten Objekten?

Ich bekomms net hin dass std::uncaught_exception true gibt... Das hab ich versucht:

#include <iostream>
#include <exception>

using namespace std;

struct Error
{
    Error() {
        cout << "Error::Error()" << endl;
        if(uncaught_exception()) {
            cout << "Uncaught Exception in Error::Error()." << endl;
        }
    }

    ~Error() {
        cout << "Error::~Error()" << endl;
    }
};

struct Foo
{

    Foo() {
        cout << "Foo::Foo()" << endl;
    }

    ~Foo() {
        cout << "Foo::~Foo()" << endl;
        if(uncaught_exception()) {
            cout << "Uncaught Exception in Foo::~Foo()." << endl;
        }
    }

    template<class T>
    void Bar(T err) {
        cout << "Foo::Bar()" << endl;
        throw err;
    }

};

int main()
{
    try {
        Foo foo;
        foo.Bar(Error()); // foo.Bar(runtime_error("x"));,
    } catch(...) {
        cout << "Exception handling in int main()" << endl;
    }
    cout << "End";
    cin.get();
}

Ausgabe (bei std-exception das selbe nur ohne Error::x meldungen)

Foo::Foo()
Error::Error()
Foo::Bar()
Error::~Error()
Error::~Error()
Foo::~Foo()
Exception handling in int main()
Error::~Error()
End

Irgendwie hab ich das net erwartet... Ich dachte mehr an:

Foo::Foo()
Foo::Bar()
Error::Error()
Uncaught Exception in Error::Error().
Foo::~Foo()
Exception handling in int main()
Error::~Error()
End

habs unter BCD6 getestet weil ich nix anderes da hab.
may be im just stupid...

/edit: der gcc sagt wieder was anderes TT

Der einzige Nachteil an dieser ganzen Geschichte ist, dass du prkatisch in jeder Funktion am Beginn die Instanzierung vornehmen musst.

Ich sage dazu nur: Aspekt Orientierte Programmierung hilft da weiter!

http://www.aspectc.org/

foo.Bar(Error()); // foo.Bar(runtime_error("x"));,

Das lokale Objekt vom Typ Error wird schon vor Ausführung des Rumpfes von Foo::Bar<>() konstruiert. Deshalb wurde noch gar keine Exception geworfen.

FireFlow schrieb:

foo.Bar(Error()); // foo.Bar(runtime_error("x"));,

Das lokale Objekt vom Typ Error wird schon vor Ausführung des Rumpfes von Foo::Bar<>() konstruiert. Deshalb wurde noch gar keine Exception geworfen.

Ok das hab ich nun kapiert... Ich hab auch verstanden dass weil ich kein Copy C'tor hab ich mehr Dekonstruktoraufrufe hab als Konstruktoraufrufe (hoffe ich zumindest dass es daran liegt, muss nochmal testen). Nun ich habs nochmal im GCC und in VC8 getestet und da bekomm ich jeweils die Meldung `Uncaught Exception in Foo::~Foo().` - Im Borland aber nicht, ist der BCB in der Hinsicht mal wieder nicht Standardkonform oder ist das Verhalten undefined?

#include <execinfo.h>

http://www.gnu.org/software/libc/manual/html_node/Backtraces.html

In unserem Projekt wird das so gemacht, dass wir nur eigene Exceptions werfen. Diese sammeln im Konstruktor die Funktionszeiger auf, die backtrace() liefert.

Wird die Exception dann gefangen, kann man sich den Backtrace mit Namen von backtrace_symbols() ausgeben lassen.

ISO/IEC 14882:1998 schrieb:

18.6.4 uncaught_exception

bool uncaught_exception();

Returns: "true" after completing evaluation of a throw-expressionuntil either completing initialization of the exception-declaration in the matching handler or entering "unexpected()" due to the throw; or after entering "terminate()" for any reason other than explicit call to "terminate()". [Note: This includes stack unwinding (15.2). --end note]

Funzt das auch im Release-Modus ohne Debug-Infos?

Ja, kann dir aber nur das sagen, was auch vorhanden ist. Das ist dann oft recht wenig.

Kann das also nur in Dekonstruktoren true ergeben?

In deinem Fall ja.

FireFlow schrieb:

Kann das also nur in Dekonstruktoren true ergeben?

In deinem Fall ja.

Hast du villeicht mal nen Beispiel wo es nicht im Dekonstruktor ist und trotzdem true ergibt? Mir fällt nix ein...

Zitat von Sutter:
Is there any other good use for uncaught_exception? Discuss and draw conclusions.

Unfortunately, I do not know of any good and safe use for std::uncaught_exception. My advice: Don't use it.

#include <iostream>
#include <exception>
using namespace std;

class Foo
{
public:
    void finalize()
    {
    	if(uncaught_exception())
            cout << "uncaught exception";
    }

    ~Foo()
    {
    	finalize();

    	// do other things
    }
};

int main()
{
	try
	{
		Foo foo;
		throw 1;
	}
	catch(...)
	{
	}
}

Oder wenn du im Destruktor ein Objekt erstellst, kann es im Konstruktor auftreten:

#include <iostream>
#include <exception>
using namespace std;

class Bar
{
public:
    Bar()
    {
    	if(uncaught_exception())
            cout << "uncaught exception";
    }
};

class Foo
{
public:    
    ~Foo()
    {
    	Bar bar;

    	// do other things
    }
};

int main()
{
	try
	{
		Foo foo;
		throw 1;
	}
	catch(...)
	{
	}
}

Aber grundsätzlich läufts über den Destruktor.

sorry, wenn ich diesen Beitrag jetzt wiederrechtlich okkupiere, aber es passt einfach zu gut zum Thema.
Ich habe mal ein bisschen mit exception specs rumgespielt. Ich hätte eigentlich gedacht, das der Compiler bei folgendem Code meckert:

void some_func() throw( exception )
{
    throw exception ( "myExcept" );
}

void MyAlloc(void) throw()
{
    some_func();
}

Ich hätte erwartet, das es zumindest ein warning giebt, da some_func ja wirft und das die spec von MyAlloc als Nothrow verletzt.
Nach diesem Artikel : http://www.gotw.ca/publications/mill22.htm :

Never write an exception specification.

Eigentlich schade, weil ich es schon ganz schön finden würde, das vom Compiler zumindest teilweise checken zu lassen, ob ein exception - system konsistent ist. Außerdem müßte ich ja auch immer auf unexpected testen, wenn ich es dennoch benutze, weil ja alle compiler (zumindest VC, und g++) das komplett ignorieren.

Eigentlich schade, weil ich es schon ganz schön finden würde, das vom Compiler zumindest teilweise checken zu lassen, ob ein exception - system konsistent ist.

Das geht aus 2 Gründen nicht. Erstens gibt es eine Menge Legacy-Code, der keine Exception-Spezifikationen enthält, obwohl er Exceptions wirft. Und zweitens kannst du bei Templates nicht wissen, welche Exceptions fliegen, da das Template-Argument beliebige Exceptions werfen kann.

Erstens gibt es eine Menge Legacy-Code, der keine Exception-Spezifikationen enthält, obwohl er Exceptions wirft

Na gut, der Fall wäre, das dieser code alles werfen kann. Das ist doch aber kein Begründung, warum man es im eigenen Code nicht wirklich verwenden kann.

Und zweitens kannst du bei Templates nicht wissen, welche Exceptions fliegen, da das Template-Argument beliebige Exceptions werfen kann

richtig, aber wenn ich eine template funktion habe, die als Nothrow (throw()) deklariert ist, dann giebt es halt einen Fehler wenn ein Template Argument verwendet wird, was eine andere spec hat.