"catch" fängt "throw" in verschachtelter funktion nicht auf

[Athar]

Wenn ich mir mal die catch-Blöcke ansehe, wundert mich das nicht weiter:

catch( eSensorFinished & e )
{
    if ( DoExtraDetectionStuff() )
        throw;
}

oder

catch( eSensorFinished & e )
{
    [...]
    throw;
}

[kaybee]

Athar schrieb:

Wenn ich mir mal die catch-Blöcke ansehe, wundert mich das nicht weiter:
....

Soweit komm ich aber gar nicht, er stürzt davor schon ab.

SeppJ schrieb:

kaybee schrieb:

KMT schrieb:

Ohne kompilierbares Minimalbeispiel und weil mir die Fehlermeldung nichts sagt kann ich nur Vermutung anstellen:

Das Problem ist, dass das Programm ein Spiel ist, was heißt du wirst mit 20-60 Zeilen Code (so, wie es in den Forenregeln steht) den Fehler nicht reproduzieren können.

Super. Dann weißt du doch schon, dass der eigentliche Fehler woanders liegt. Jetzt musst du nur noch rausfinden, wann das Problem weggegangen ist, als du den Code gekürzt hast.

Ich hab nur gemeint es würde theoretisch nicht gehen. Klar könnte ich jetzt das ganze auf sowas hier reduzieren:

#include <iostream>

using namespace std;

class eSensorFinished {};

void triggerSensor() {
    throw eSensorFinished();
}

int main()
{
    try {
        triggerSensor();
    }
    catch(eSensorFinished &e) {
        cout << "caught eSensorFinished" << "\n";

    }
}

Aber wirklich weiterhelfen würde das nicht, da der Code hier wunderbar läuft, während das Spiel aber abschmiert.

[Athar]

kaybee schrieb:

Soweit komm ich aber gar nicht, er stürzt davor schon ab.

Wie hast du das festgestellt? Debuggst du etwa mit -O2? Wo ist -g?

[kaybee]

Athar schrieb:

kaybee schrieb:

Soweit komm ich aber gar nicht, er stürzt davor schon ab.

Wie hast du das festgestellt? Debuggst du etwa mit -O2? Wo ist -g?

Oh mein Fehler, ich hab die arguments von der Release Version gepostet Debug sieht so aus:

mingw32-g++.exe -fexceptions -DWIN32 -D_CONSOLE -D_MBCS -DEMBEDDED -DDONTUSEMEMMANAGER -DNO_SOCKLEN_T  -g -W -D_DEBUG -DDEBUG

[KMT]

Ich hab rausgefunden warum mir die "Fehlermeldung" nix sagt. Das ist einfach nur der stacktrace. Und offensichtlich nichtmal der ganze.

Was heißt denn eigentlich "er stürzt ab"? terminate()? unhandled exception? segfault?

Davon abgesehen hast du glaube ich denn Sinn eines kompilierbaren Minimalbeispiels nicht ganz verstanden. Wenn du uns Code lieferst der funktioniert, dann werden wir da - Überraschung - auch keinen Fehler finden. Betrifft übrigens auch deinen Eröffnungsbeitrag.
Genausowenig haben die Leute hier aber Lust - und vorallem Zeit - sich durch tausende Zeilen code durchzuarbeiten.

Tatsächlich wird es in deinem Projekt ziemlich sicher tausende Zeilen von code geben, die man einfach rausstreichen (bzw auskommentieren) kann, und der Fehler wird immer noch auftreten. In 90% der Fälle findet man dann den Fehler sogar direkt selber.
Schau dir doch einfach mal den call stack an, und kommentier einfach die funktion calls aus, die nicht im call stack bis zum Fehler drinnen sind. Vielleicht hast du Abhängigkeiten zu Ladefunktion - auskommentieren/hardcoden.
Ich glaub dir einfach nicht, dass es nicht gehen soll, weil ich (und nebenbei auch andere hier) sowas eben oft genug gemacht haben.

[kaybee]

Ich hab den Code schon soweit runter kommentiert, dass das Spiel nicht mehr crasht. Und zwar einfach indem ich alle Funktionen die "throw" werfen auskommentiert habe. Insofern weiß ich nicht, wo ich da weitermachen sollen.

Es ist ja auch Fakt, dass bei anderen Leuten der selbe Code nicht crasht und das verwirrt mich doch sehr

[theta]

Bei dem Namen

eSensorFinished

für die Exception könnte man glatt denken, Du setzt Exceptions zur Ablaufsteuerung ein, was man aber nicht sollte. Sie sind nicht das geeignete Mittel dafür.

[kaybee]

Das ist mir bewusst, aber es ist wie gesagt nicht mein Code und ich will ihn auch nicht grundlegend verändern

[hustbaer]

Rebuild-All gemacht?
Verwenden alle Module den selben Exception-Handling Modus (sjlj vs. Dwarf-2)?
Wirfst du Exceptions über DLL Grenzen?

[kaybee]

1. Ja, mehrmals
2. Ich benutze MinGW GCC 4.4.1 welches seit Version 3.4 sjlj gar nicht mehr ünterstützt
3. Nein, die throw Funktion(en) und auch alles was davor kommt, passiert nur im Hauptprogramm selber

[hustbaer]

Vielleicht Funktionsaufrufe über Funktionszeiger oder extern "C" Funktionen? Bzw. schonmal in der MinGW/GCC Doku nachgesehen in welchen Fällen der Compiler davon ausgeht dass nixe geworfen wird?

Bzw. ... funktioniert alles wenn du das "throw" durch z.B. eine globale Variable + if + return "nachstellst"?
Mir drängt sich nämlich schön langsam der Verdacht auf dass du Speicher kaputthaust.

[kaybee]

hustbaer schrieb:

Bzw. ... funktioniert alles wenn du das "throw" durch z.B. eine globale Variable + if + return "nachstellst"?
Mir drängt sich nämlich schön langsam der Verdacht auf dass du Speicher kaputthaust.

Verstehe nicht ganz, was du meinst, vielleicht könntest du es mir etwas genauer erklären

Ich hab jetzt mal folgendes probiert:

void testfunction()
{
    throw eSensorFinished();
}

void gSensor::PassEdge(const eWall *ww,REAL time,REAL a,int r){
    if (!ww)
        return;

    try{
        //eSensor::PassEdge(ww,time,a,r);
        testfunction();
    }
    //catch( eSensorFinished & e )
    catch(...)
    {
    }

und er bleibt jetzt bei testfunktion hängen, liegt also nicht an dem code der in der funktion eSensor::PassEdge vor dem throw steht