Was ist schneller: Fehlercode oder Exception?

[Blaze]

Hi Leute!
Was ist eigentlich schneller / besser geeignet: Die Rückgabe eines Fehlercodes, Eine Exception, beides?

Was würdet iht verwenden?
Dies

int foo(bool b)
{
if(b) return(-1);
return(0);
}
...
if(foo(1 oder 0))
{
//Do something
}

oder das hier

void foo(bool b)
{
if(b) throw(-1);
}
...
try
{
foo(1 oder 0)
}
catch(const int i)
{
//Do Something
}

Was ist besser?

[Shade Of Mine]

Es gibt genau einen Grund warum man Error Codes verwenden will. Naemlich dann wenn man keine andere Moeglichkeit hat. Ansonsten will man die nie nie nie verwenden.

Lies dir mal Teil 1 und Teil 2 von meinem Artikel durch.

[und]

man sollte auch genau unterscheiden, ob es wirklich ein fehler ist oder nicht. element nicht gefunden ist z.B. keiner.

[Blaze]

und schrieb:

man sollte auch genau unterscheiden, ob es wirklich ein fehler ist oder nicht. element nicht gefunden ist z.B. keiner.

Gibt's dafür eine Art Ordnung oder ist das jedem selbst überlassen?
Gerade "Element nicht gefunden" oder "Datei nicht gefunden" ist da fragwürdig.

[und]

Wenn du in einer map was suchst und es nicht da ist, dann ist das ja kein fehler. wenn du eine datei z.b. mit findfirstfile suchst und nichts findest, dann ist das auch kein fehler. wenn du auf eine datei nicht zugreifen kannst, weil sie plötzlich gelöscht wurde oder gerade von nem anderen programm blockiert wird ist das ein fehler den du vorher auch nicht prüfen konntest. man sollte halt unterscheiden ob es das ergebins ist oder ein fehler.

[Shade Of Mine]

Blaze schrieb:

und schrieb:

man sollte auch genau unterscheiden, ob es wirklich ein fehler ist oder nicht. element nicht gefunden ist z.B. keiner.

Gibt's dafür eine Art Ordnung oder ist das jedem selbst überlassen?
Gerade "Element nicht gefunden" oder "Datei nicht gefunden" ist da fragwürdig.

Die Frage ist immer: was ist die intention?

Will ich eine Datei oeffnen, aber die Datei ist nicht da? Exception.
Ueberpruefe ich ob eine Datei da ist? keine Exception.

Suche ich gerade das x-te Element und finde es nicht? keine Exception.
Will ich gerade das x-te Element bearbeiten und es ist nicht vorhanden? Exception.

idR ist es sehr simpel das festzulegen. schwieriger ist festzulegen welche exception fliegt...

[*john 0]

Blaze schrieb:

Gibt's dafür eine Art Ordnung oder ist das jedem selbst überlassen?

Immer dann, wenn das Programm in einen undefinierten Zustand abzurutschen drohnt, logischerweise muß man das testen, wirft man eine Exception. Man muß unbedingt die zugesicherten Eigenschaften einer Softwarekomponente einhalten, klappt dies nicht -> Exception.

[BUlli]

Seit wann heißt Exception Fehler? Wenn mich mein Englisch nicht täusch, heißt Exception Ausnahme. Und man wirft dann eine Exception, wenn eine Ausnahmesituation eintritt. Elemenet in Map nicht gefunden, ist eine Ausnahmesituation.

[Shade Of Mine]

BUlli schrieb:

Seit wann heißt Exception Fehler? Wenn mich mein Englisch nicht täusch, heißt Exception Ausnahme. Und man wirft dann eine Exception, wenn eine Ausnahmesituation eintritt. Elemenet in Map nicht gefunden, ist eine Ausnahmesituation.

Wenn ich map[key]=value mache und key ist nicht da, dann Ja.
Wenn ich aber isset(map[key]) bzw. map.find(key) mache - dann NICHT.

Und Exceptions werden zum anzeigen von Fehlern verwendet. Und zwar von bestimmten Fehlern. Man darf nicht alles immer woertlich nehmen...

[drakon]

Shade Of Mine schrieb:

idR ist es sehr simpel das festzulegen. schwieriger ist festzulegen welche exception fliegt...

Und imo auch, wenn man eine exception fängt richtig darauf zu reagieren.

[Dravere]

Und am schlimmsten ist es Exceptions über Threadgrenzen hinaus zu werfen. Das ist äusserst hässlich. Da kommt man dann oft um Fehlercodes nicht mehr wirklich rum.

Grüssli

[*john 0]

Shade Of Mine schrieb:

Wenn ich aber isset(map[key]) bzw. map.find(key) mache - dann NICHT.

Wie sind die zugesicherten Eigenschaften der Softwarekomponente? Wenn man bei Design der Applikation erwartet, daß die Map den Key enthält, dann ist eine Exception gerechtfertigt. Wenn dem nicht so war natürlich nicht.

[pumuckl]

Blaze schrieb:

Hi Leute!
Was ist eigentlich schneller / besser geeignet: Die Rückgabe eines Fehlercodes, Eine Exception, beides?

Was würdet iht verwenden?

Das sind im Grunde drei verschiedene Fragen, auf die es wohl auch drei verschiedene Antworten gibt.

- Was ist schneller?
Sollte imho keine Rolle spielen, zumal Fehler nicht gehäuft auftreten sollten. Ein Programm sollte im Fehlerfall lieber Augenmerk auf Korrektheit und Sicherheit als auf Schnelligkeit legen.

- Was ist besser geeignet?
Kommt drauf an. RAII geht z.B. Hand in Hand mit Exceptions, da Destruktoren automatisch aufgerufen werden. Alles von Hand aufzuräumen und dann einen Fehlercode zurückzugeben ist da schon mehr Tippaufwand und fehleranfälliger. Schreibt man auf der anderen Seite eine Bilbiothek die unter Umständen sogar eine C-Schnittstelle liefert, ist man mit Fehlercodes vermutlich besser beraten, schließlich kennt C keine Exceptions in dem Sinne. Auf jeden Fall sollte man nicht beides mischen sondern eine einheitliche Fehlerbehandlung nutzen.

- Was würdet ihr verwenden?
Ist wohl persönlicher Geschmack. Ich persönlich verwende Exceptions, weil if-Fehlercode-Abfragen den Code zerpflücken, weil Exceptions eben objektorientierte Ansatz zur Fehlerbehandlung sind und weil sie eben mit anderen Features wie RAII besser zusammenarbeiten.

[Shade Of Mine]

~john schrieb:

Shade Of Mine schrieb:

Wenn ich aber isset(map[key]) bzw. map.find(key) mache - dann NICHT.

Wie sind die zugesicherten Eigenschaften der Softwarekomponente? Wenn man bei Design der Applikation erwartet, daß die Map den Key enthält, dann ist eine Exception gerechtfertigt. Wenn dem nicht so war natürlich nicht.

Nein, da gibt es nichts zu diskutieren: wenn ich sage frage
"hat die map den key X"
dann ist die antwort ja oder nein.

Eine exception darf maximal fliegen wenn die map nicht well-formed ist, zB unbalanziert ist oder sonstige invarianten nicht mehr stimmen. wobei in c++ dann ein assert passieren wuerde.

nie nie nie eine exception werfen auf eine frage: "gibt es X?" wenn X nicht da ist.

wenn ich eine exception will weil X immer da sein muss, dann mache ich eine funktion getX() die find macht und not_found bei fehlerfall wirft.

[*john 0]

Shade Of Mine schrieb:

Nein, da gibt es nichts zu diskutieren: wenn ich sage frage
"hat die map den key X"
dann ist die antwort ja oder nein.

Korrekt, aber darauf bezog sich das Beispiel nicht. Es ging explizit darum, ob bei der Verwendung einer Map

class A {
  std::map<std::string, ValueType> map_;
public:
   ValueType foo (std::string cont& key) {
    ...
    if (map_.end() == map_.find(key)) {
      // soll man hier werfen oder nicht
    }
    ...
  }
};

eine Exception werfen soll oder nicht. Das hängt davon ab, welche Anforderungen an A gestellt werden.

Shade Of Mine schrieb:

Eine exception darf maximal fliegen wenn die map nicht well-formed ist, zB unbalanziert ist oder sonstige invarianten nicht mehr stimmen.

Das ist ein vollständig anderes Problem, und zwar das Problem ob und wann die Member Function map::find eine Exception werfen darf.

[C++-Profi]

Verwende Exceptions, die if-Abfragen von Error-Codes verhunzen dir nur den Cache wegen falscher Branch-Predictions deiner CPU.

[Shade Of Mine]

~john schrieb:

Korrekt, aber darauf bezog sich das Beispiel nicht. Es ging explizit darum, ob bei der Verwendung einer Map

class A {
  std::map<std::string, ValueType> map_;
public:
   ValueType foo (std::string cont& key) {
    ...
    if (map_.end() == map_.find(key)) {
      // soll man hier werfen oder nicht
    }
    ...
  }
};

eine Exception werfen soll oder nicht. Das hängt davon ab, welche Anforderungen an A gestellt werden.

Dann quote das richtige...

ohne zu wissen was foo ist, kann man nicht sagen was passieren soll, aber die funktion sieht von der signatur her sehr stark nach "eine exception muss fliegen" aus.

[pumuckl]

~john schrieb:

Shade Of Mine schrieb:

Eine exception darf maximal fliegen wenn die map nicht well-formed ist, zB unbalanziert ist oder sonstige invarianten nicht mehr stimmen.

Das ist ein vollständig anderes Problem, und zwar das Problem ob und wann die Member Function map::find eine Exception werfen darf.

Das kann exakt das selbe Problem sein - nämlich dann wenn es zu jedem "gültigen" Argument von foo() einen Eintrag in der map geben muss - was dann eine Invariante von A wäre. Die gültigen Argumente müssten dann natürlich über eine precondition festgelegt sein.

[und]

Shade Of Mine schrieb:

BUlli schrieb:

Seit wann heißt Exception Fehler? Wenn mich mein Englisch nicht täusch, heißt Exception Ausnahme. Und man wirft dann eine Exception, wenn eine Ausnahmesituation eintritt. Elemenet in Map nicht gefunden, ist eine Ausnahmesituation.

Wenn ich map[key]=value mache und key ist nicht da, dann Ja.

Nein, nicht bei std::map
http://msdn.microsoft.com/en-us/library/fe72hft9(VS.80).aspx

map::operator[]

Inserts an element into a map with a specified key value.

Type& operator[](
const Key& _Key
);

Parameters

_Key

The key value of the element that is to be inserted.

Return Value

A reference to the data value of the inserted element.
Remarks

If the argument key value is not found, then it is inserted along with the default value of the data type.

~john schrieb:

class A {
  std::map<std::string, ValueType> map_;
public:
   ValueType foo (std::string cont& key) {
    ...
    if (map_.end() == map_.find(key)) {
      // soll man hier werfen oder nicht
    }
    ...
  }
};

eine Exception werfen soll oder nicht. Das hängt davon ab, welche Anforderungen an A gestellt werden.

Wenn ein Element in der Map sein müsste, aber nicht da sein kann, wenn ein logikfehler im programm ist, dann würde ich ein assert verwenden, weil das schon beim entwickeln auffallen muss.

[Bashar]

pumuckl schrieb:

- Was ist schneller?
Sollte imho keine Rolle spielen, zumal Fehler nicht gehäuft auftreten sollten. Ein Programm sollte im Fehlerfall lieber Augenmerk auf Korrektheit und Sicherheit als auf Schnelligkeit legen.

So interpretiert ist das in der Tat eine sinnlose Frage. Vielleicht ist ja die Geschwindigkeit im Nicht-Fehlerfall gemeint. Meinjanur ...

weil Exceptions eben objektorientierte Ansatz zur Fehlerbehandlung sind

Ist das so? Was ist es denn, das Exceptions zum objektorientierten Ansatz macht?