spieleprogrammierer.de - Forum und Wiki zur Spieleprogrammierung und Spieleentwicklung

Ich halte das mit try/catch so, dass ich eigentlich ein try in der main habe und dann das dazugehörige catch, wo ich dann den Fehler ausgebe.

Wenn ich etwas auf einer tieferen Stufe behandeln kann, dann wird das natürlich vorher gefangen, aber das ist eher selten.

Das assert Makro ist nicht für Fehlerbehandlung beim User gedacht, sondern für den Entwickler. Darum wird das im Release alles wegoptimiert. Assertions sind dazu gedacht, dass man sie an den Anfang von funktionen hat und den Input prüft. Dann werden z.B mit Unittests die Funktionen getestet und wenn es ein Problem gibt, schläft das assert an und gibt einem den Hinweis wo ein Fehler passiert ist. Wenn also die Tests in Ordnung verlaufen, dann ist es ein Problem des Testings, wenn ein Fehler trotzdem noch auftaucht.

Exceptionbehandlung (try&catch) kostet grundsätzlich mehr, als Fehler per return Wert zurück zu geben. Wenn man also Exceptions benutzt, sollte man das im Hinterkopf haben, relevant ist das meiner Meinung nach aber nur an Stellen die wirklich enorm schnell sein müssen und sehr oft benutzt werden.
Ich benutze boost::exception, damit kann man sehr einfach die Fehlerbeschreibung über mehrere Ebene verfeinern (Fehler wird in der LoadTexture Methode geworfen, die kann aber nicht wissen, welches Material von welchem Modell das jetzt betrifft), so kann man damit wirklich gute Fehlermeldungen bekommen.

Bei Exceptions muss man natürlich immer darauf achten, dass der Code Exceptionsafe ist, also z.B. smartpointer benutzen. Und daran denken, dass Exceptions Ausnahmen sein sollten, und sie daher auch nur für Fehler und so benutzen und nicht um irgendwelche Sachen standardmäßig zurück zu geben.