Enum

[stackcpu]

Hallo zusammen

Was hätte es für ein Nutzen wen ich ein enum als Rückgabewert einer Methode benutzen würde. Nur ein Beispiel

enum eTest
{
	eRichtig,
	eFalsch,
	eFatalError
};

eTest klasse::methode(int x, int y)
{

// wenn rechnung richtig 
return eRichtig;

//wenn rechnung falsch
return eFalsch;

//wenn alles scheisse 
return FatalError

;
}

[Belli]

Du könntest erkennen, ob die Methode erfolgreich war.

[SeppJ]

Was hätte es für ein Nutzen wen ich ein enum als Rückgabewert einer Methode benutzen würde.

Die Antwort des dogmatisch durchdesignten C++ (die dadurch aber nicht falsch ist): Keinen, außer eine gewisse Kompatibilität zu C. Für so etwas wurden Exceptions erfunden. enums haben andere Anwendungen und Rückgabewerte sind für Ergebnisse da, nicht für Fehlermeldungen.

[stackcpu]

Okey danke vielmals

[daddy_felix]

SeppJ schrieb:

Was hätte es für ein Nutzen wen ich ein enum als Rückgabewert einer Methode benutzen würde.

Die Antwort des dogmatisch durchdesignten C++ (die dadurch aber nicht falsch ist): Keinen, außer eine gewisse Kompatibilität zu C. Für so etwas wurden Exceptions erfunden. enums haben andere Anwendungen und Rückgabewerte sind für Ergebnisse da, nicht für Fehlermeldungen.

Das gilt nur für den Fall, dass das Enum - wie in diesem Beispiel - zum Fehlertransport verwendet wird.

Generell kann es sehr sinnvoll sein, ein enum zurückzugeben:

enum geschlecht { MANN, FRAU };

geschlecht GeschlechtVon(const Person& person)
{
  if (person.HatShoppingTick())
    return FRAU;

  return MANN;
}

[Sone]

Was hätte es für ein Nutzen wen ich ein enum als Rückgabewert einer Methode benutzen würde.

Ganz viele. Du könntest zum Beispiel das zurückgegebene Enumerations-Objekt auf seinen Wert prüfen.

In diesem speziellen Fall würde man aber zu Exceptions greifen.

[sdfsdf]

enum AmpelPhase
{
  Rot,
  Gruen,
  Gelb
};

AmpelPhase BerechnePhase()
{
  // ...

  if (AndererVerkehrHatVorrang)
    return Rot;

  return Gruen;
}

[dogmatiker]

SeppJ schrieb:

Für so etwas wurden Exceptions erfunden. enums haben andere Anwendungen und Rückgabewerte sind für Ergebnisse da, nicht für Fehlermeldungen.

Da muss mindestens noch angemerkt werden, dass manchmal enum/bool als Rückgabewert eine bessere Alternative zu Exceptions sind, wenn man daran interessiert ist, zu wissen, ob es einen Fehlerfall gab. Oft ist das egal und Fehler werden bis zu einem zentralen catch-Block durchgereicht, aber manchmal will man das nicht. Ein direktes try{f();}catch(sth){} ist Zeichen von Java-like Exception-Übernutzung

[Sone]

dogmatiker schrieb:

SeppJ schrieb:

Für so etwas wurden Exceptions erfunden. enums haben andere Anwendungen und Rückgabewerte sind für Ergebnisse da, nicht für Fehlermeldungen.

Da muss mindestens noch angemerkt werden, dass manchmal enum/bool als Rückgabewert eine bessere Alternative zu Exceptions sind, wenn man daran interessiert ist, zu wissen, ob es einen Fehlerfall gab. Oft ist das egal und Fehler werden bis zu einem zentralen catch-Block durchgereicht, aber manchmal will man das nicht. Ein direktes try{f();}catch(sth){} ist Zeichen von Java-like Exception-Übernutzung

Hier muss man aber klar zwischen einer Ausnahme (die eigentlich nicht im Programmablauf vorkommen sollte) und einem erwarteten Ergebnis unterscheiden. Wenn Streams eine Zahl nicht parsen können, dann ist das durchaus erwartet (für spezielle Fälle gibt es auch noch exceptions() ), daher ist der Fehler dort durch einen State ausgedrückt.

Der aber wiederum natürlich keinen Rückgabewert darstellt...

[Marthog]

In deinem Beispiel würde ich ein boolean für richtig und falsch zurückgeben und für fatal-error eine exception auslösen.
Beispiel: Die Funktion sagt einer Spielfigur, sie soll zu der Koordinate (x|y) gehen. Der Rückgabewert gibt an, ob die Aktion erfolgt (true) oder der Weg versperrt ist (false), wenn (x|y) aber außerhalb des Spielfelds liegt, sollte mit einer Exception reagiert werden.

Bei C++11 würde ich enum class verwenden, das vermüllt nicht den Scope.