try catch und Release Version

Artchi

Ergänzung zum Dump (finde ich auch eine super Sache!): Auf welchem Warnlevel arbeitest du? Wenn du den Warnlevel höher setzt, hätte der Compiler dir bestimmt gesagt, das test nicht korrekt initialisert wurde. Das hindert dich zwar nicht das Ding trotzdem auszuführen, aber er hat dich schon beim Kompilieren auf eine potenzielle Gefahrenquelle hingewiesen. Damit kann man schon mal Ärger minimieren.

BOA

simon.gysi schrieb:

Quälcode

ui.. schon so gequält..

Nein, ernsthaft. Meinst Du ein Compiler Fehler?
Dann versuchts mit:
int *test = 0;
*test = 13;
Gruss Simon

Genau,

Compilerfehler, war schlecht ausgedrückt von mir...

Grüße

BOA

BOA

Artchi schrieb:

Ergänzung zum Dump (finde ich auch eine super Sache!): Auf welchem Warnlevel arbeitest du? Wenn du den Warnlevel höher setzt, hätte der Compiler dir bestimmt gesagt, das test nicht korrekt initialisert wurde. Das hindert dich zwar nicht das Ding trotzdem auszuführen, aber er hat dich schon beim Kompilieren auf eine potenzielle Gefahrenquelle hingewiesen. Damit kann man schon mal Ärger minimieren.

Hi,

ja das mit dem Dump würde ich auch gerne nutzen und verstehen. Da bin ich gerade dran, eventuell erbarmt sich Martin noc einmal, mir zu antworten...

Ja, klar, bei dem jetzigen Code warnt er natürlich. Ich wollte mit dem Beispielcode nur einen Abbruch erzwingen, um prinzipiell mein try catch Problem in Verbindung mit Release hier darzustellen...

Danke und Grüße

BOA

Softwaremaker

Also wenn ich bei eingeschalteter Optimierung /O2 folgendes ausführe:

try
{
   int *test=NULL;

   *test = 31;
}

catch(...)
{
   AfxMessageBox("try-catch ok");
}

Release: Windows-Fehlermeldung erscheint (catch wird nicht aufgerufen)
Debug: MsgBox "try-catch ok" (catch wird aufgerufen)
Im Debug ist Optimierung deaktiviert!

Release ohne Optimierung: MsgBox "try-catch ok" (catch wird aufgerufen)

-> Optimierung entfernt try-catch-Mechanismus

siehe auch: http://members.cox.net/doug_web/eh.htm
"...If you were to examine the assembly language emitted for this program, you would find the compiler has optimized all the exception handling machinery out of the function, because the optimizer can determine the tried code cannot throw a C++ exception."

(WinXP, VC++ 6.0)

Update:
aber wenn man nach
int *test=NULL;
ein "CString msg;" einfügt kommt catch auch bei Release mit Optimierung.
-> Sehr merkwürdiger Optimierer

simon.gysi

"...If you were to examine the assembly language emitted for this program, you would find the compiler has optimized all the exception handling machinery out of the function, because the optimizer can determine the tried code cannot throw a C++ exception."

Ja, aber die __try / __except (SEH) wird dann nicht weg optimiert.

catch(...) ist ein mix zwischen C++ Exception Handling und SEH.

Edit: Ist das Verhalten bei VS2005 / VS2008 dasselbe? VC++6.0 ist doch schon sehr in die jahre gekommen und nicht sehr ISO Compliant.

Martin Richter

Martin Richter schrieb:

Warum so kompliziert und DUMPCHK verwenden.

Nimm VS.
Öffne die DMP Datei als Projekt und sage einfach F5 (Start Debug) und staune...

Wie ich es gesagt habe.
Einfach auf Projekt Öffnen gehen. Dort alle Dateien (inkl. .dmp) anzeigen lassen. Die dmp Datei öffnen (ja das geht!), F5 drücken und jetzt Staunen...

hustbaer

OMFG.
Dashier ist schlimmer als wenn man dem Fleischer beim Wurst-Machen zusieht.
Ich werde nie wieder ein Programm anfassen welches ich nicht selbst geschrieben habe!

@BOA: Verwende doch bitte einfach _set_se_translator oder __try/__except.
z.B. so:

int poese()
{
	int volatile*p = 0;
	*p = 0;
	return 0;
}

int main()
{
	__try
	{
		return poese();
	}
	__except(EXCEPTION_EXECUTE_HANDLER)
	{
		printf("poese!!!\n");
		return 1;
	}
}

Und sag bitte nicht nochmal das funktioniere nicht. Das funktioniert! (Und _set_se_translator funktioniert auch)

BOA

hustbaer schrieb:

OMFG.
Dashier ist schlimmer als wenn man dem Fleischer beim Wurst-Machen zusieht.
Ich werde nie wieder ein Programm anfassen welches ich nicht selbst geschrieben habe!

@BOA: Verwende doch bitte einfach _set_se_translator oder __try/__except.
z.B. so:
int poese()
{
	int volatile*p = 0;
	*p = 0;
	return 0;
}

int main()
{
	__try
	{
		return poese();
	}
	__except(EXCEPTION_EXECUTE_HANDLER)
	{
		printf("poese!!!\n");
		return 1;
	}
}
Und sag bitte nicht nochmal das funktioniere nicht. Das funktioniert! (Und _set_se_translator funktioniert auch)

Hehe,

dann wirst Du viele gute und hilfreiche Programme nicht kennen lernen...
Vor allen Dingen so ohne Betriebssystem auf Deinem Rechner, viel Spass beim entwickeln...

Danke für Deinen Code, teste ich mal und berichte...

@Martin Richter
Ich glaube wir arbeiten mit verschiedenen Versionen, Martin.

Ich habe das VS 6, da kann ich nen Arbeitsbereich öffnen, aber kein Projekt, oder, ja schlagt mich, ich weiß net wo...

Ich weiß, ist ne schwere Geburt, aber das Kind scheint gesund, bitte hilf ihm...

Grüße und Danke

BOA

sri

Mit VS6 geht das noch nicht.

BOA

sri schrieb:

Mit VS6 geht das noch nicht.

Ahhhh....

Danke, ich war der Verzweiflung nahe...

Grüße

BOA

Martin Richter

Wer arbeitet auch noch mit VC6... <duck&wech>

BOA

hustbaer schrieb:

OMFG.
Dashier ist schlimmer als wenn man dem Fleischer beim Wurst-Machen zusieht.
Ich werde nie wieder ein Programm anfassen welches ich nicht selbst geschrieben habe!

@BOA: Verwende doch bitte einfach _set_se_translator oder __try/__except.
z.B. so:
int poese()
{
	int volatile*p = 0;
	*p = 0;
	return 0;
}

int main()
{
	__try
	{
		return poese();
	}
	__except(EXCEPTION_EXECUTE_HANDLER)
	{
		printf("poese!!!\n");
		return 1;
	}
}
Und sag bitte nicht nochmal das funktioniere nicht. Das funktioniert! (Und _set_se_translator funktioniert auch)

Hey,

funktioniert immer noch nicht...
Nur Spasss...
Jetzt funktioniert es, dank der Konstanten innerhalb der __except(). Muß einem doch gesagt werden...

Wobei ich dazu erwähnen muss, dass die andere Variante auch funktioniert, sprich viele Wege führen nach Rom.
So haben wir wenigstens alle mal durch...

Danke für die Hilfe.

Grüße

BOA

BOA

hustbaer schrieb:

OMFG.
Dashier ist schlimmer als wenn man dem Fleischer beim Wurst-Machen zusieht.
Ich werde nie wieder ein Programm anfassen welches ich nicht selbst geschrieben habe!

@BOA: Verwende doch bitte einfach _set_se_translator oder __try/__except.
z.B. so:
int poese()
{
	int volatile*p = 0;
	*p = 0;
	return 0;
}

int main()
{
	__try
	{
		return poese();
	}
	__except(EXCEPTION_EXECUTE_HANDLER)
	{
		printf("poese!!!\n");
		return 1;
	}
}
Und sag bitte nicht nochmal das funktioniere nicht. Das funktioniert! (Und _set_se_translator funktioniert auch)

Jetzt ist mir doch noch etwas aufgefallen. Ich bekomme folgende Warning beim Einsatz Deiner Variante :

D:\Microsoft Visual Studio\MyProjects\VTSM_Server\VTSM_ServerDlg.cpp(570) : warning C4509: Nicht dem Standard entsprechende Erweiterung : 'MessageReceive' verwendet SEH, und 'tUser' besitzt einen Destruktor

es wird innerhalb der "__try" tatsächlich ein Destruktor verwendet. Sowas macht mich schon wieder skeptisch und schärft die Überlegung doch nicht diese Variante zu nutzen, denn was will der Compiler mir sagen ?
Klar benutze ich nen Destruktor, warum schafft das ein Problem mit SEH ?

Nerv...

*Ergänzung*
Vor lauter warnings habe ich auch folgende Error Meldung bekommen :

D:\Microsoft Visual Studio\MyProjects\VTSM_Server\VTSM_ServerDlg.cpp(868) : error C2712: __try kann nicht in Funktionen verwendet werden, die eine Objektentladung benoetigen

Also, doch wieder zurück zur anderen Variante... Das nervt hier doch ungemein...

Grüße

BOA

simon.gysi

Weil beim SEH kein Stack Unwinding durchgeführt wird.
Der vorhandene Destruktor deutet jedoch darauf hin, es es nötig sein würde.

Desshalb meldet der Compiler dir die Inkompatiblität.

simon.gysi

Im MSDN nachlesen würde helfen.

BOA

simon.gysi schrieb:

Im MSDN nachlesen würde helfen.

Danke für den hinweis!

Oder aber Simon.gysi fragen...
Soziale Kontakte sind gerade für Softwareentwickler wichtig!

Grüße und Danke

BOA

hustbaer

Weil beim SEH kein Stack Unwinding durchgeführt wird.

Nope, weil er den nötigen compiler switch nicht gesetzt hat. Selbst VC6 kann das, bloss wenn er sich zu fein ist in der MSDN nachzusehen werde ich ihm jetzt auch nicht sagen wie der verkackte switch heisst mit dem er das einschalten kann.

BOA

hustbaer schrieb:

Weil beim SEH kein Stack Unwinding durchgeführt wird.

Nope, weil er den nötigen compiler switch nicht gesetzt hat. Selbst VC6 kann das, bloss wenn er sich zu fein ist in der MSDN nachzusehen werde ich ihm jetzt auch nicht sagen wie der verkackte switch heisst mit dem er das einschalten kann.

Lol...

Der Sinn eines Forums ist die Kommunikation, ansonsten könnte fast jede Anfrage hier mit "Guck in die MSDN" beantwortet werden.

Beim Hinweis auf die MSDN muss man aufpassen, wann sie Sinn macht, ansonsten hat man schnell den unrühmlichen Titel Neunmalkluger oder Klugsch... auf seiner Fahne stehen.
Bedenke, nicht jeder ist so toll und multilingual wie Du, hustebaerchen...

So leid es mir tut, die Lösung von softwaremaker ist für mein Problem der deutlich bessere Tip.

Grüße

BOA

simon.gysi

simon.gysi schrieb:

Weil beim SEH kein Stack Unwinding durchgeführt wird.
Der vorhandene Destruktor deutet jedoch darauf hin, es es nötig sein würde.

Desshalb meldet der Compiler dir die Inkompatiblität.

Ok, habe blödsinn erzählt. Sorry!
Gruss Simon