Return value im Falle von Try-Catch
Code: Alles auswählen
bool DieKlasse::dieFunktion()
{
try
{
/*
some code....
*/
return true;
}
catch(...)
{
// Benutzer wird benachrichtigt durch bspw. eine MessageBox
// return false;
}
}
Du meinst: zuerst geht es in dem catch weiter und, falls das abschließt, dahinter.Alexander Kornrumpf hat geschrieben:Ich dachte immer dass es wenn die Ausnahme gefangen wird einfach nach dem catch weiter geht.
Doch, doch. Das Problem hat mit Ausnahmebehandlung nichts zu tun – Funktionen dürfen in C++ sehr wohl keinen Rückgabewert haben, das ist dann nur eben undefiniertes Verhalten (außer bei int main()). Ebenso möglich, aber vollständig definiert und saubere Praxis ist, dass die Funktion überhaupt nicht zurückkehrt indem sie innerhalb des catch-Blocks wieder eine Ausnahme wirft (und damit die Kontrolle an den nächstäußeren catch-Block übergibt) oder terminate() aufruft (und das Programm damit beendet). Und was nicht zurückkehrt, braucht auch nichts zurückzugeben.joggel hat geschrieben:Anscheinend habe ich das Prinzip von Exceptions nicht ganz verstanden.
Mit "gefangen" meinte ich tatsächlich "gefangen und ohne weitere Probleme behandelt" und mit "catch" meinte ich den catch-Block. Was zugegeben sträflich unpräzise war.Krishty hat geschrieben:[Du meinst: zuerst geht es in dem catch weiter und, falls das abschließt, dahinter.
Code: Alles auswählen
public boolean doSomething()
{
int i = 4;
if( i < 10 )
{
return true;
}
}
Interessant. Ich habe von Java gehört, dass es tote Pfaden hinter return, throw und system.exit zuverlässig erkennt und in diesem Fall meckert. Ändert sich dein Beispiel vielleicht, wenn du i final deklarierst?Jaw hat geschrieben:Was der Compiler allerdings leider nicht merkt ist, wenn ein Pfad praktisch nicht zu erreichen ist. Mal primitiv gesagt
Da würde er meckern, weil er halt nicht merken kann, dass die Bedingung immer erfüllt wäre. Das nur so als Anekdote, son Fall hatte ich mal. Man spendiert ihm dann einfach den extra return und gut is.Code: Alles auswählen
public boolean doSomething() { int i = 4; if( i < 10 ) { return true; } }
Halteproblem.joggel hat geschrieben:Wieso meckert der Kompiler nicht?
Uff, schwere Lektüre zum Montagmorgen... aber danke!!Krishty hat geschrieben: Ach, und wth kam eigentlich diese Antwort noch nicht:Halteproblem.joggel hat geschrieben:Wieso meckert der Kompiler nicht?
Code: Alles auswählen
// HalteProblem_2.cpp : Definiert den Einstiegspunkt für die Konsolenanwendung.
//
//#include "stdafx.h"
#include <iostream>
bool test()
{
try
{
return true;
}
catch(...)
{
}
}
int main(int argc, char* argv[])
{
test();
return 0;
}
Code: Alles auswählen
...
//Qt-Header und eigene eingebunden
int test()
{
}
int main(int argc, char* argv[])
{
cout << test() << endl;
// Meine Qt- Application ... weiß das jetzt leider nicht mehr!
....
}
Code: Alles auswählen
// HalteProblem_2.cpp : Definiert den Einstiegspunkt für die Konsolenanwendung.
//
//#include "stdafx.h"
#include <iostream>
int main(int argc, char* argv[])
{
int test(0);
try
{
test=10;
//return 0;
}
catch(...)
{
}
//return test;
}
------ Erstellen gestartet: Projekt: HalteProblem_2, Konfiguration: Debug Win32 ------
Kompilieren...
HalteProblem_2.cpp
d:\programmierung\projekte\halteproblem_2\halteproblem_2\halteproblem_2.cpp(17) : warning C4100: 'argv': Unreferenzierter formaler Parameter
d:\programmierung\projekte\halteproblem_2\halteproblem_2\halteproblem_2.cpp(17) : warning C4100: 'argc': Unreferenzierter formaler Parameter
Das Buildprotokoll wurde unter "file://d:\Programmierung\Projekte\HalteProblem_2\HalteProblem_2\Debug\BuildLog.htm" gespeichert.
HalteProblem_2 - 0 Fehler, 2 Warnung(en)
========== Erstellen: 1 erfolgreich, Fehler bei 0, 0 aktuell, 0 übersprungen ==========
joggel hat geschrieben:Nicht mal mehr auf C++ kann man sich verlassen...
Ja, solche Querverweise gibt es zum Glück häufiger. Beispielsweise sind die Formeln der Informatik, mit denen Shannon die Entropie in Signalen maß und die in der Datenkompression eine große Rolle spielen, dieselben, mit denen man später in der Thermodynamik die Entropie hinter dem Ereignishorizont Schwarzer Löcher berechnen konnte. Gibt mir den Trost, dass nicht alle Probleme, gegen die ich programmiere, von menschlichem Mind selber erschaffene Scheinprobleme sind.joggel hat geschrieben:Was ich eben auch durch den Link gefunden habe, dieser Gödelscher Unvollständigkeitssatz fand ich echt toll!!
Wenn keine Rekursion benutzt wird, und keine Schleifen mit variabler Endbedingung benutzt werden, ist die betreffende Teilsprache nicht Turing-mächtig. Nimmt man jetzt noch ein paar Hilfsmittel hinzu (Datentypen haben nur endlich viele Werte, d.h. wir sind nicht auf einer Real-RAM), kann dieses Problem sehr wohl statisch gelöst werden.Krishty hat geschrieben:Halteproblem.joggel hat geschrieben:Wieso meckert der Kompiler nicht?
Hab hier nicht alles gelesen, aber ist doch klar, dass der Compiler hier nicht meckert, jedenfalls falls Optimierungen eingeschaltet sind. Ich würde mir eher Sorgen machen wenn der Compiler hier nicht feststellen könnte, dass sowohl der catch-Block als auch der Teil nach dem try/catch niemals aufgerufen werden können.joggel hat geschrieben:Code: Alles auswählen
bool DieKlasse::dieFunktion() { try { /* some code.... */ return true; } catch(...) { // Benutzer wird benachrichtigt durch bspw. eine MessageBox // return false; } }
Hmm also bei mir verursacht der folgende Code schon eine Warnung im VS2008:joggel hat geschrieben:Naja, dieser Abschnitt der durch /* some code*/ beschrieben wurde, enthält ja ordentlich Code, wo es möglich wäre das Exception gewurfen werden. Das hat mich halt nur verwundert.
Code: Alles auswählen
void func()
{
}
bool blub()
{
try
{
func();
return true;
}
catch (const std::exception &e)
{
}
}