"Sauberes" return

DragonRaider

Hi dot,
Ist OK. Nur das throw muss ich auch irgendwo hin setzen...
Naja ich schätze mal die Form der Wahl wäre dann:

void load(params)
  {
  ID = SOIL_load_OGL_texture(params);
  if(ID == 0)
    {
    throw "Unable to load texture!";
    }
  }
(...)
unsigned int ID;

Oder habe ich dich da was falsch verstanden(habe zwar von throw gehört, es aber, bis jetzt, noch nie genutzt)?

MfG
DragonRaider

Nathan

Ja, so geht es zwar, in der Regel schmeißt man aber eine Ausnahmeklassenobjekt.
Die Standardbibliothek bietet hier eine ganze Hierachie an, die alle von std::exception abgeleitet sind.
Dann kann man nämlich einfach

try
{

}
catch (std::exception &ex)
{

}

um alle Ausnahmen zu fangen.

Der Vergleich (==) liefert bereits einen Wahrheitswert. Ein

return ID != 0;

wäre demnach übersichtlicher gewesen.

Nichts desto trotz sind hier exceptions angebracht. Definiere jedoch eine eigene Ausnahmeklasse (z. B. von std::exception erben) und werfe nicht einfach einen string.

Ave

DragonRaider

Hi Nathan,
Danke, für die Hilfe/den Tipp. Ich hab jetzt mal www.google.de befragt, da wird folgendes vorgeschlagen:

struct myException : std::exception
{
const char* what() const noexcept
  {
  return "myException(description)";
  }
};

Entschuldigung, falls die Frage dumm ist, aber gibt es da auch noch ne "kürzere" Methode? Soweit ich den Code hier verstehe nein, aber...
Danke schon mal bis hier hin .

MfG
DragonRaider

Nathan

Ja.
Es gibt die Klasse "runtime_error", die für deine Fälle ausreicht.
Im Konstruktor übergibst du einfach die Fehlermessage und kannst sie dann abfragen.

knivil

Nun, Exceptions vs Return-Values. Das haengt von Vorlieben, Objektinvarianten und Programmarchitektur. Ich persoenlich wuerde im vorliegenden Fall keine Exception werfen. Die Exception kann das Objekt in enem ungueltigen Zustand zuruecklassen. Ausserdem wuerden ueberall try-catches auftauschen. Ich wuerde die Texturklasse so gestallten, dass sie mit fehlerhaftem Laden umgehen kann. Das fehlerhafte Laden sollte in der Entwicklung trotzdem in einer Logdatei protokolliert werden.

Eine Moeglichkeit, ist z.B. dass eine leere Textur ein gueltiger Zustand ist und alle Operationen mit Texturen damit umgehen muessen. Das fuehrt dann zu Code wie if(tex.valid()) { ... } else ( ... } und ist auch sehr unschoen.

Meine bevorzugte Moeglichkeit, eine Dummytextur zu nutzen. D.h. bei Fehlschlag wird eine Dummytextur erzeugt. Das Dach des Hauses ist dann eben nicht braun, sondern ist weiss mit roter Schrift "Fix me". Nachfolgende Operationen brauchen sich dann keine Gedanken machen, ob die Textur gueltig ist. Sie ist es in jedem Fall. Wird die Dummytextur nicht algorithmisch generiert sondern ebenfalls irgendwann am Anfang des Programms geladen, dann wuerde ich eine Exception werfen.

Nathan

Meine Texturklasse hat einen Default-Ctor, will man sie aber laden und das schlägt fehl gibts ne Exception. Und das ganze hat sogar noch eine starke Garantie.

knivil

starke Garantie

Das bedeutet?

Nathan

Die Textur an sich ist genau so wie vorher auch.

DragonRaider

Hi,
Ich finds echt "schön", dass sich hier so eine kleine Disskusion los getreten hat . Ich denke, ich werde das mit der "Fix Me" Textur übernehmen und im Releasemode(ohne Konsole) dann auch eine "errors.txt" haben, in der Fehler, verursacht durch fehlende Texturen etc., genau mitgeloggt werden.
Nun zur eigentlichen Frage:
Wenn ich's mit ner boolschen Funktion löse, wäre denn dann 1., 2., 3. oder 4. am saubersten?
MfG
DragonRaider

Caligulaminus

Stechus Kaktus' Variante?

&quot;Sauberes&quot; return

"Sauberes" return