ich sehe aktuell drei Optionen, damit ich zwischen meinen Programmbausteinen merke, ob und wann etwas schief läuft: a) Exceptions, b) stets einen Status returnieren und pruefen, c) dem Objekt ein Attribut errorCode spendieren, dass im Konstruktor mit 0 besetzt wird und nur im Fehlerfall mit einem Fehlercode ueberschrieben wird.

Ich schwanke zwischen b und c, vermutlich nutze ich dann beides, das Attribut kann ich von ueberall her abfragen und pruefen und bei einem gescheiterten return-Code sehe ich direkt, wo es geknallt hat.

Was denkt ihr, welche Ansätze haben sich für euch bewährt?

Ich habe etwas Bammel gehabt, dass mir ja der Programmfluss mit einer Exception abhaut, dazu die zusätzliche Komplexität. Ebenso steht im Google-C++-Guide, dass die komplett auf Exceptions in deren Projekten verzichten, daher dachte ich, dass ich das auch so machen sollte. Aber naja, nachdem ich nun etwas nachgelesen habe, denke ich versuche ich mich mal kurz an Exceptions, in Java klappte das ja auch, wenn mir da IDE und Sprache auch einiges abgenommen hat.

Also los gehts mit Exceptions und C++ für mich:

// 1. Die Funktion wo es vielleicht kracht ...

double Facade::computePairEntropyOfStrings(const std::string& stringToComputeOne, const std::string& stringToComputeTwo) {
  try {
    checkForSameStringLength(stringToComputeOne, stringToComputeTwo);
  } catch( H2rException &e ){
    std::cout << e.what() << std::endl;
    std::cerr << e.what() << std::endl;
  } catch(...) {
    throw; // schmeiss hoch
  }
  seqan::CharString columnStringOne(stringToComputeOne);
  seqan::CharString columnStringTwo(stringToComputeTwo);
  double res = getPairEntropyOfColumnStrings(columnStringOne, columnStringTwo);
  return res;
}

// 2. Die Funktion die als Werfer markiert ist ... 
void Facade::checkForSameStringLength(const std::string& stringToComputeOne, const std::string& stringToComputeTwo){  
  if ( stringToComputeOne.size() != stringToComputeTwo.size() ){
    throw H2rException;
  }
}

// 3. Meine Exception-Klasse
// aus Schneeweiss S. 161f
class H2rException : public std::exception 
{
public:
  H2rException(char *where) : txt(where) {}
  const char* what() const throw();
private:
  char *txt;
};

const char* H2rException::what() const throw()
{
  static std::string s;
  s = "H2rException ist in ";
  s += txt;
  s += " aufgetreten.";
  return s.c_str();
}

... okay, mal schauen ob das klappt, aber es sollte nichts schiefgehen, da
- wenn meine Exception erkannt wird, dann wird etwas Text ausgegeben und weiter nach oben geworfen, also terminate ausgeführt.
- wenn eine andere Exception erkannt wird, dann wird durch die Ellipse auch terminate() aufgerufen, ich brauche mir also keine Sorgen machen, dass eine Exception auftritt, die unentdeckt bleibt. Habe ich das richtig verstanden?

Deine Exception-Klasse solltest du von einer der von std::exception abgeleiteten Klassen ableiten. Da gibt es z.B. length_error. Also könntest du deine Klasse wie folgt definieren:

// Error ist viel sexier als Exception
struct H2rError : std::length_error
{
    H2rError(const std::string& msg)
        std::length_error(msg)
    {}
};

Komisch, mir fiel auch auf, dass da teilweise unterschiedliche Header eingebunden werden in den Beispielen, daher die Bitte nach einem kompilierbaren Beispiel.

Fehlermeldung:
h2rerror.h: In member function ‘virtual const char* H2rError::what()’:
In file included from facade.h:16,
from main.h:9,
from main.cpp:4:
h2rerror.h:11: error: expected primary-expression before ‘,’ token
h2rerror.h: At global scope:
h2rerror.h:14: error: redefinition of ‘const char* H2rError::what()’
h2rerror.h:11: error: ‘virtual const char* H2rError::what()’ previously defined here
h2rerror.h:14: error: expected unqualified-id before ‘{’ token

Das Beispiel kommt von hier http://www.rpg-studio.de/scientia/C%2B%2B/Tutorial:_16._Fehlerbehandlung#Eigene_Exceptionklassen und wenn ich das Beispiel via Copy und Paste in ein neues Projekt stelle, dann klappt das auch - jemand eine Idee?

const char* H2rException::what() const throw()
{
  static std::string s;
  s = "H2rException ist in ";
  s += txt;
  s += " aufgetreten.";
  return s.c_str();
}

static std::string s; ?
Wirklich?

Konkret fallen mir zwei Dinge auf: Erstens ist what() throw() nicht genug; die von std::exception verwendete Signatur ist

virtual char const *what() const throw();

Zweitens gehört die Definition der Methode nicht in den Header, sondern in eine eigene Übersetzungseinheit, sonst kriegst du damit später Linkerfehler. Beides wird deinen Compilerfehler aber nicht auslösen, sondern würde dir erst später Probleme verursachen. Die Fehlermeldung

h2rerror.h:11: error: expected primary-expression before ‘,’ token

gekoppelt mit der völligen Abwesenheit von Kommata in deinem Code macht mich ziemlich sicher, dass sich da ein Tippfehler eingeschlichen hat, den du nicht mit herauskopiert hast.

Und vor Internettutorials hat man dich doch hier bestimmt auch schon gewarnt.

@SeppJ das heisst ich sollte nur die Exceptions der STL nutzen und keine 'eigenen' bauen sollen?

Das mit dem Error-Handling scheint mir echt mühsam und tricky zu sein, gerade wenn da wohl erst vor einiger Zeit Ansätze als deprecated eingestuft wurden.

Naja, die Community weiss eigentlich seit vielen Jahren dass die Exception-Specs in C++ nicht wirklich sinn machen.
Da C++11 das erste echte Update für C++ ist (C++03 war bloss ne Revision des 98er Standards), konnten sie natürlich auch erst jetzt deprecated gemacht werden.

Es ist ja auch so, dass die Kritik an Exception-Spezifikationen sich vor allem gegen solche richtet, die nur bestimmte Exceptions erlauben. Die Garantie zu geben, dass überhaupt keine Exception geworfen werden kann, ist auch im neuen Standard nicht veraltet, und ob jetzt throw() oder noexcept da steht, ist erst mal von mäßiger Wichtigkeit.

Bei throw() war vorgeschrieben dass unexpected() aufgerufen wird wenn doch was geflogen kommt. Und unexpected() war es wiederum erlaubt selbst Exceptions zu werfen.
Ein Programm konnte sich also nicht darauf verlassen, dass aus einer throw() Funktion niemals was rausfliegt.

Bei noexcept ist es dagegen garantiert. Wenn sich das Programm nicht daran hält, dann wird terminate() aufgerufen. Und terminate() darf eben keine Exceptions werfen.

Naja, bis ich da auf einem grünen Zweig bin, nehme ich assert-statements und exit mit Fehlercode - gibts halt jedesmal einen Abbruch, wenn irgendwo etwas schiefläuft.

assert ist okay, um Logikfehler zu finden. Aber niemals für Laufzeitfehler. Und wieso exit() ?

Naja, gibt schon Unterschiede zwischen throw() und noexcept.

Bei throw() war vorgeschrieben dass unexpected() aufgerufen wird wenn doch was geflogen kommt. Und unexpected() war es wiederum erlaubt selbst Exceptions zu werfen.
Ein Programm konnte sich also nicht darauf verlassen, dass aus einer throw() Funktion niemals was rausfliegt.

Bei noexcept ist es dagegen garantiert. Wenn sich das Programm nicht daran hält, dann wird terminate() aufgerufen. Und terminate() darf eben keine Exceptions werfen.

Das ist so nicht ganz korrekt. std::unexpected darf zwar eine Exception werfen, diese wird aber nur aus der Funktion herausgereicht, wenn sie entweder eh auf die Spezifikation passt oder die Spezifikation std::bad_exception beinhaltet, in welchem Fall die geworfene Exception durch ein std::bad_exception-Objekt ersetzt wird. Andernfalls wird std::terminate aufgerufen. So oder so kommt nichts aus der Funktion, was nicht in der Exception-Spezifikation steht. (Vgl. 15.5.2 (2) in C++03)

Nochwas: bei noexcept ist glaube ich vorgeschrieben dass kein Stack-Unwinding vor dem Aufruf von terminate() stattfindet. Auch ein Unterschied zu (und IMO eine Verbesserung gegenüber) throw(), wo Stack-Unwinding vorgeschrieben ist.

C++11 15.5.1 (2) schrieb:

In such cases, std::terminate() is called (18.8.3). In the situation where no matching handler is found, it is implementation-defined whether or not the stack is unwound before std::terminate() is called. In the situation where the search for a handler (15.3) encounters the outermost block of a function with a noexcept-specification that does not allow the exception (15.4), it is implementation-defined whether the stack is unwound, unwound partially, or not unwound at all before std::terminate() is called. In all other situations, the stack shall not be unwound before std::terminate() is called. An implementation is not permitted to finish stack unwinding prematurely based on a determination that the unwind process will eventually cause a call to std::terminate().

Jay1980 schrieb:

Naja, bis ich da auf einem grünen Zweig bin, nehme ich assert-statements und exit mit Fehlercode - gibts halt jedesmal einen Abbruch, wenn irgendwo etwas schiefläuft.

assert ist okay, um Logikfehler zu finden. Aber niemals für Laufzeitfehler. Und wieso exit() ?

Mir geht es nur darum, dass ich ein zu Ende laufen des Programms verhindern will, wenn ich merke, dass die Daten im Programm fehlerhaft sind - da dachte ich, wie ziehe ich denn am besten den Stecker und mir kam exit() und assert() - je nachdem, wie ich gerade pruefen kann. Ich habe aber nur den Thread da gesehen, http://www.c-plusplus.net/forum/210888 und exit() scheint doch nicht so der Bringer zu sein, es wäre schon besser das Programm 'sanft' aber in jedem Fall zu beenden. Bei assert muss ich aufpassen, dass mir in der Release-Version nicht automatisch die Prüfung wegfällt, daher auch keine optimale Lösung, normalerweise sollten die assert-Statements da ja draußen oder entwertet sein, wenn ich das richtig verstanden habe.

Okay, mir scheint folgender Weg als geeignet: ich werfe einfach immer exceptions, aber lege dafür eben keine eigene Exception-Klasse an. Am Ende meines catch-Blocks beende ich das Programm in dem ich nach oben weiter werfen lasse, das heisst, das irgendwann terminate() kommt und ein sanftes Ende eintritt - soweit richtig?

Code poste ich dann, wenn ich damit etwas rumprobiert habe.

class my_error : public std::exception
{
     public:
         my_error(const std::string &err) : std::exception(err)
         {};
};

throw my_error("Da ist was schief gelaufen");

Hier noch ein paar Infos:
http://msdn.microsoft.com/en-us/library/t65b74ad.aspx

@Artchi: So sah ja auch mein Vorschlag aus.