3. "Sauberes" return

"Sauberes" return

  • N

    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.

    0
  • ?

    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

    0
  • D

    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

    0
  • N

    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.

    0
  • K

    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.

    0
  • N

    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.

    0
  • K

    starke Garantie

    Das bedeutet?

    0
  • N

    Die Textur an sich ist genau so wie vorher auch.

    0
  • D

    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

    0
  • C

    Stechus Kaktus' Variante?

    0
Anmelden zum Antworten