Exceptions in C++ hui oder pfui?

[pumuckl]

x8000 schrieb:

Ist für euch eine Exception == Programmende? Oder warum soll man die nur in main fangen?

Niemand hat gesagt dass man grundsätzlich Exceptions nur in der main fangen soll. volkard möchte seine AssertionException nur in der main fangen. Vermutlich weil die nur dann ausgelöst wird, wenn ein Programmierfehler/Logikfehler enthalten ist (Assertion eben), und dann das Programm an sich eh zum Teufel ist und nicht verlässlich weiter verwendet werden kann.
Grundsätzlich sollten Exceptions imo auf Subsystem-Ebene gefangen werden, d.h. wenn ein Subsystem einen so schwerwiegenden Fehler hat, dass es nicht sinnvoll weiterarbeiten kann, wirft es die Exception und fertig. Der Aufrufer sollte dann diese Exception fangen und entweder ordentlich behandeln oder aber eine zu seinem Subsystem passende Exception weiterwerfen.
Beispiel Parse-Fehler in der save-Datei:
Wenn der Parser komplett aussteigt, weil die Datei unkenntlich ist, schmeißt er eine SaveFileParseException. Das Modul, das den Parser aufgerufen hat, kann jetzt entweder eine Warnmeldung ausgeben á la "Save-Datei kaputt, starte leeres Dokument", wenn das angemessen ist, oder es wirft eine eigene Exception, dass es eine nötige Datei nicht laden konnte. Die Info, was beim Parsen schiefgelaufen ist, die vermutlich in der SaveFileParseException zu finden ist, interessiert an höherer Stelle vielleicht garnicht mehr.
Auf jeden Fall bedeutet das "aus dem Modul rauswerfen", dass mehrere Funktionen durchflogen werden, bevor die exception gefangen wird. Try/Catch brauchts es bei so einer Behandlung nur an Modulgrenzen. Ein grundsätzlich exceptionsicherer Code muss weder komplexer noch imperformanter als "normaler" Code sein, das bedeutet unter anderem, dass vielleicht zwei oder drei von ~100 Funktionen im Modul eine Exception werfen können, die anderen Funktionen aber nicht mit Fehlerbehandlungscode zugemüllt werden müssen. Das ist ein Gegensatz zum alten C-Errorcode Gedöns, wo erstens die Errorcodes in so ziemlich jede Schnittstelle wandern müssen, um rausgereicht zu werden, und zweitens in jeder Funktion die Errorcodes der aufgerufenen Funktionen aufgesammelt, ausgewertet und weitergereicht werden müssen.
Und selbst wenn aus irgendwelchen Gründen mein Modul einen Errorcode zurückliefern soll, dann tun das die 5-10 Funktionen, die zur äußeren Schnittstelle des Moduls gehören. Intern fliegen weiter lustig Exceptions, die an den Außengrenzen gefangen und als Errorcodes zurückgegeben werden.
Ein weiterer Vorteil von Exceptions gegenüber Errorcodes ist, dass Klienten meines Moduls sie fangen/behandeln müssen und nicht mit einem korrumpierten Programm sorglos weiterarbeiten. Ich habe schon viel zu oft C-Style ErrorCodes gesehen, die einfach ignoriert wurden. Häufig landen dann Anfragen bei mir oder Kollegen, warum "das denn nicht tut", und wir müssen dann mühsam debuggen.
@ volkard: __asm int 3 sagt mir jetzt nichts. Du schreibst, dass der Debugger an der Stelle hält. Um welchen Debugger gehts? MSVC hat eine Funktionalität, dass man beim Wurf von vorher auszuwählenden Exceptions ein break im Debugging bekommt.

[__niemand__]

vorschlag schrieb:

Verlinkt doch mal ein Open Source C++ Projekt, dass eurer Meinung nach Exceptions effektiv verwendet.

http://paludis.pioto.org/

[volkard]

TyRoXx schrieb:

Und wenn man Referenzen verwendet, wo Referenzen angebracht sind, muss man sogar nicht einmal auf Nullzeiger testen.

Fail. Referenzen sollte man anders benutzen, als Du postulierst und auch dann muß man nicht auf Nullzeiger testen. Aber das ist ein anderes Thema.

[volkard]

pumuckl schrieb:

@ volkard: __asm int 3 sagt mir jetzt nichts. Du schreibst, dass der Debugger an der Stelle hält. Um welchen Debugger gehts?

Ich denke, alle tuns auf Intel.
http://en.wikipedia.org/wiki/INT_(x86_instruction)#INT_3
Breakpoints anders zu implementieren, wäre irgendwie, gegen die Hardware zu arbeiten.

Das da war für den MSVC: http://www.c-plusplus.net/forum/23425-13

Und heute unter Linux getestet mit gcc und gdb:

#include <iostream>
using namespace std;

int main() {
    for(int i=0;i<10000;++i){
        cout<<i<<endl;
        if(i==9876) asm("int $0x03");
    }
}

Klappt auch wie gewünscht.

pumuckl schrieb:

MSVC hat eine Funktionalität, dass man beim Wurf von vorher auszuwählenden Exceptions ein break im Debugging bekommt.

Ich finde es im Code hübscher.

[pumuckl]

Ich sehe jetzt den Zusammenhang von deinem beispiel mit Exceptions nicht ganz, hab da wohl ein brett vorm Kopf.

volkard schrieb:

pumuckl schrieb:

MSVC hat eine Funktionalität, dass man beim Wurf von vorher auszuwählenden Exceptions ein break im Debugging bekommt.

Ich finde es im Code hübscher.

Ich bin kein Freund von Dingen im Code, die nichts mit der Programmfunktionalität zu tun haben. Exceptions, um unvorhergesehene Probleme anzuzeigen, ja. Für Programmierfehler oder Logikfehler definitiv nicht. Debughilfen haben im normalen Code auch nichts verloren. asserts mag ich auch nicht unbedingt. Schließlich gibts unit-Tests, die ein Interface breit genug testen sollten.

[volkard]

pumuckl schrieb:

Ich bin kein Freund von Dingen im Code, die nichts mit der Programmfunktionalität zu tun haben.

Nichtmal #pragma(lib, ?
Ich freue mich, wenn man einfach nur den Quellcode in ein Projekt kopieren muß und schon funktioniert es. Und umgekehrt würde ich manchmal gerne Leute erschlagen, die (selbstverständlich ohne Doku, denn nur der Code wird dokumentiert) verlangen, daß man zwei bis drei Stunden lang die Einstellungen sucht, die zu machen sind, um den vorliegenden Quellcode lauffähig zu kriegen.

pumuckl schrieb:

Exceptions, um unvorhergesehene Probleme anzuzeigen, ja. Für Programmierfehler oder Logikfehler definitiv nicht.

Meine AssertExceptions sind keine Debughilfe, sondern Aufräumhilfe im assert-Fall. Also ich werde von assert in den Debugger geworfen. Dort untersuche ich die lokalen Variablen und stelle eine These auf, welchen Fehler ich gemacht hatte. Und dann stoppe ich das Programm, aber nicht mit Strg+F5 (Debugger abbrechen), sondern mit F5 (Programm weiterlaufen lassen), erst jetzt wird die Exception geworfen und eventueller Aufräumcode wird noch ausgeführt.

pumuckl schrieb:

Debughilfen haben im normalen Code auch nichts verloren.

Doch, klar!

pumuckl schrieb:

asserts mag ich auch nicht unbedingt. Schließlich gibts unit-Tests, die ein Interface breit genug testen sollten.

Hä??

[TyRoXx]

volkard schrieb:

TyRoXx schrieb:

Und wenn man Referenzen verwendet, wo Referenzen angebracht sind, muss man sogar nicht einmal auf Nullzeiger testen.

Fail. Referenzen sollte man anders benutzen, als Du postulierst und auch dann muß man nicht auf Nullzeiger testen. Aber das ist ein anderes Thema.

Wie denn?

[dot]

volkard schrieb:

pumuckl schrieb:

Ich bin kein Freund von Dingen im Code, die nichts mit der Programmfunktionalität zu tun haben.

Nichtmal #pragma(lib, ?

Also ich find #pragma comment(lib, "bla") ist eine wirkliche Unart. Sowas hat im Source-Code nun wirklich nichts zu suchen, das ist Aufgabe des Buildsystems.

[314159265358979]

+1 für dot.

@Topic: Eindeutig pfui. Ich bin die ganze try-catch-Scheiße leid.

[einwurf]

volkard schrieb:

Was aber auch gilt: In C++ werfen wir tunlichst keine Exceptions bei Programmierfehlern (Stack Underflow, Arraygrenzenüberschreitung und so) und auch nicht bei ganz normalen Sachen wie einem Dateiende.

Da ich mich gerade mit beschäftige - wie wird es richtig gemacht?
Eventuell gibt es noch bessere Möglichkeiten

template <typename T>
class Threadsave_stack
{
 private:
  std::stack<T> data;
  mutable std::mutex m;
 public:
  std::unique_ptr<T> pop() 
};

Exception-Variante:

template <typename T>
std::unique_ptr<T> Threadsave_stack<T>::pop()
{
 std::lock_guard<std::mutex> lock(m);
 if(data.empty()) throw Empty_stack("Stack is empty");
 std::unique_ptr<T> res(new T(std::move(data.top())));
 data.pop();
 return res;
}

nullptr-Variante.

template <typename T>
std::unique_ptr<T> Threadsave_stack<T>::pop()
{ 
 std::lock_guard<std::mutex> lock(m); 
 if(!data.empty())  
 { 
  std::unique_ptr<T> res(new T(std::move(data.top()))); 
  data.pop(); 
  return res; 
 } 
 return std::unique_ptr<T>(nullptr); 
}

[pumuckl]

volkard schrieb:

pumuckl schrieb:

Ich bin kein Freund von Dingen im Code, die nichts mit der Programmfunktionalität zu tun haben.

Nichtmal #pragma(lib, ?

Siehe dot.

Ich freue mich, wenn man einfach nur den Quellcode in ein Projekt kopieren muß und schon funktioniert es. Und umgekehrt würde ich manchmal gerne Leute erschlagen, die (selbstverständlich ohne Doku, denn nur der Code wird dokumentiert) verlangen, daß man zwei bis drei Stunden lang die Einstellungen sucht, die zu machen sind, um den vorliegenden Quellcode lauffähig zu kriegen.

Projekte mit so vielen Enstellungen sind mir bisher noch nicht untergekommen. Makefiles bzw. MSVC-Solutions haben mir bisher immer gereicht.

pumuckl schrieb:

Debughilfen haben im normalen Code auch nichts verloren.

Doch, klar!

Wenn ich sie zum Debuggen grade brauche, baue ich das entsprechende Modul mit ein paar Zeilen Debughilfe. Danach kommen sie wieder raus. Debugrelikte von anno dunnemals, die nie wieder benötigt werden, sobald der Code stabil ist, sorgen nur für Verwirrung und verursachen unnötigen Maintenance-Aufwand. Ich weiß, Code ändert sich und man muss wieder debuggen, aber dann passen meistens die alten Debughilfen eh nicht mehr zum neuen Code.

pumuckl schrieb:

asserts mag ich auch nicht unbedingt. Schließlich gibts unit-Tests, die ein Interface breit genug testen sollten.

Hä??

Ich nutze keine Assertions. Wozu auch? Wenn ein assert sicherstellen würde, dass die Eingaben in eine Schnittstelle bestimmte Kriterien erfüllen, dann stelle ich in meinen Unit-Tests sicher, dass die aufrufenden Funktionen die Schnittstelle immer mit ordentlichen Eingaben bestücken. Wenn ein assert sicherstellen würde, dass ich von irgendwo ordentliche Rückgabewerte bekomme, teste ich das genauso über Unit-Tests, Regressionstests usw.

314159265358979 schrieb:

@Topic: Eindeutig pfui. Ich bin die ganze try-catch-Scheiße leid.

pumuckl schrieb:

Das Wichtigste zum Umgang mit Exceptions ist allerdings die Aussage, dass exceptionsicherer Code nichts mit andauerndem try/catch zu tun hat. Leider verstehen das viele Leute immernoch nicht.

[pumuckl]

einwurf schrieb:

Da ich mich gerade mit beschäftige - wie wird es richtig gemacht?
Eventuell gibt es noch bessere Möglichkeiten

Exception-Variante/nullptr-Variante.

Da bei Multithreading immer ein anderer Thread dir den Stack vor der Nase weg leeren kann, würde ich die nullptr-Variante bevorzugen. Alternativ eine blockierende Variante, die bei leerem Stack wartet, bis wieder was zu poppen ist.

[TyRoXx]

einwurf schrieb:

Da ich mich gerade mit beschäftige - wie wird es richtig gemacht?
Eventuell gibt es noch bessere Möglichkeiten

Hast du schon das in Betracht gezogen?

template <class T>
bool tryPop(T &value);

Die Variante mit dem unique_ptr blockiert mit dem unnötigen new den Stack relativ lange. Wenn es unbedingt unique_ptr sein muss, könnte man das Element erst bewegen, den Mutex wieder freigeben und dann new bemühen.

[volkard]

dot schrieb:

Also ich find #pragma comment(lib, "bla") ist eine wirkliche Unart. Sowas hat im Source-Code nun wirklich nichts zu suchen, das ist Aufgabe des Buildsystems.

Wenn Ihr dann wenigsten //#pragma comment(lib, "bla") in die Datei schreiben würdet! Dann konnte man sich das zusammenklauben und im Build-System eintragen. Aber das ist nicht der Fall.

[dot]

Wieso sollte ich das machen? Ich verwend einfach ein vernünftiges Buildsystem...

[volkard]

dot schrieb:

Wieso sollte ich das machen? Ich verwend einfach ein vernünftiges Buildsystem...

Also nicht MSVC?
Weil die benötigten Libs direkt von den inkludierten Headers abhängig sind (oder gemacht werden können), dann kann ich das #pragma(lib auch in den Header schreiben und der Header ist dann sogar in dieser Hinsicht self-sufficient.
Socketklasse in anderem Projekt benötigt? Null Problemo. Durch das inkludieren der Socket.hpp weiß ich ja automatisch, daß die ws2_32.dll dazugelinkt werden muß. Es ist halt einen kleinen Schritt weiter, als nur in die Socket.hpp zu schreiben "Lieber Benutzer! Diese Datei und die zugrörige *.cpp benutzen Funktionen aus der ws2_32.dll. Vergiß nicht, in den Linkereinstellungen einzustellen, daß die ws2_32.lib dazugelinkt werden muß.".
Und ich nezweifle jetzt auch, daß Dein Build-System das macht, sondern ich nehme an, Du hast einen Haufen von libs, die dazugelinkt werden, aber hast keinen Bezug mehr, warum welche lib benötigt wird und wenn Du Dateien fremdgehen lassen willst, bemerkst Du, daß Dir solche Kommentare durchaus fehlen.
Wobei ich im Kopf habe, warum ich welche libs dazugenommen habe. Aber wie lange? Und kann mein Nachfolger Gedanken lesen? Also ich kann jedenfalls die Gedanken meiner Vorgänger nicht lesen.

[dot]

volkard schrieb:

Also nicht MSVC?

MSVC ist kein Buildsystem. VCBuild war mal eines und MSBuild ist eines und letzteres verwend ich. Schonmal was von Property Sheets gehört?

[314159265358979]

pumuckl schrieb:

314159265358979 schrieb:

@Topic: Eindeutig pfui. Ich bin die ganze try-catch-Scheiße leid.

pumuckl schrieb:

Das Wichtigste zum Umgang mit Exceptions ist allerdings die Aussage, dass exceptionsicherer Code nichts mit andauerndem try/catch zu tun hat. Leider verstehen das viele Leute immernoch nicht.

Das hast du nun aber falsch verstanden. Nochmal besser formuliert: Ich bin es _generell_ leid, try-catch zu verwenden, weil die Syntax so unglaublich umständlich und hässlich ist. Das heißt nicht, dass ich's dauernd verwende

[volkard]

dot schrieb:

volkard schrieb:

Also nicht MSVC?

MSVC ist kein Buildsystem. VCBuild war mal eines und MSBuild ist eines und letzteres verwend ich. Schonmal was von Property Sheets gehört?

"Property Sheet" kann alles bedeuten. Vermutlich ist damit ein Property Sheet gemeint.
http://msdn.microsoft.com/en-us/library/windows/desktop/bb774538(v=vs.85).aspx

Ich fürchte, Du willst mir jetzt was verkaufen, wie man mit grafischen Dialogen was erreichen kann, was als eine Zeile Code viel besser gelöst wäre.

[dot]

Nö, ich mein eigentlich das: http://msdn.microsoft.com/en-us/library/a4xbdz1e.aspx
Damit kann beispielsweise jeder Entwickler des Teams an bekannten Orten (z.B. MSBuild Extensions Directory) Property Sheets für alle möglichen Versionen aller möglichen Libs und SDKs die er so installiert hat ablegen.
Ein VC++ Projekt verweist dann einfach auf die entsprechenden .props Dateien der benötigten libs und fertig. Damit kann jeder Entwickler seine Dateien organisieren wie er will und auch 100 verschiedene Versionen aller möglichen libs halten und trotzdem funktioniert jedes Projekt einfach so out of the box. Da muss ich dann weder irgendwelchen Code irgendwohin kopieren noch irgendwelche libs irgendwo eintragen. Und nur weil Visual Studio selbstverständlich eine GUI zum Editieren von Propery Sheets bietet, heißt das noch lange nicht, dass ich auf die angewiesen bin. Die GUI ist doch nur ein bequemes Interface zum Buildsystem.
Mit deiner Zeile Code wär das imo überhaupt nicht besser gelöst, denn das pragma ist plattform-/compilerspezifisch und kommt mit verschiedenen Versionen, Suchpfaden, etc. rein prinzipiell schon nicht klar. Sowas gehört eben einfach nicht in den Code, genau für sowas gibts doch überhaupt erst ein Buildsystem...