try catch in jeder funktion?

[xyz123]

hat schon mal jemand so etwas gesehen? ich war irretiert. was haltet ihr davon?

void blub
{
   try
   {
      ..nur hier code!
   }
   catch(...)
   {
      writelog(fehler in blub)
   }
}

und das wirlkich im ganzen programm, durchweg!

mfg

[CStoll]

Für Debug-Zwecke könnte sowas eventuell nützlich sein, aber im produktiven Code halte ich das etwas für übertrieben - da sollten Fehler nur dort abgefangen werden, wo man auch mit ihnen umgehen kann.

(wobei, vielleicht stammt der Autor auch aus VB und hat das "on error goto..." konsequent verinnerlicht)

[xyz123]

naja, im prinzip kann man ja damit umgehen. im logfile steht ja drin wo.
das programm stürzt halt nie ab, interessiert sich allerding auch nicht für "verlorenen" speicher o.ä. wenn was passiert.

[LordJaxom]

xyz123 schrieb:

naja, im prinzip kann man ja damit umgehen. im logfile steht ja drin wo.

Interessanter Ansatz.
"Der Motor brennt" - "Notiers im Logbuch, danach kümmer Dich nicht weiter drum"

Aber das sieht in der Tat nach VB-Herkunft aus. Unsere VB-Funktionen beginnen auch grundsätzlich mit on error goto bzw. in neueren Programmen Try...Catch

das programm stürzt halt nie ab, interessiert sich allerding auch nicht für "verlorenen" speicher o.ä. wenn was passiert.

Eben

[thordk]

sieht für mich nach nem fall von mit kanonen auf spatzen aus. exceptions sollten gezielt gefangen und auf gezielt behandelt werden. wenn ich so einen code sehe - am besten noch vor jeder verwendung eines pointers die prüfung auf null pointer - ist das für mich ein indiz dafür, dass da jemand am werk war, der sich wenig gedanken darüber gemacht hat, was in einem stück code passiert und schiefgehen kann.

[xyz123]

die frage ist doch eigentlich: hat es denn auch nachteile?
immerhin erhält der user niemals "schwerer ausnahmefehler in..."

ist nicht schön - weiß ich aber
- ist es denn langsamer? wohl kaum.
- verbrauchts mehr speicher? sicher auch nicht.

hmmmm?

[CStoll]

xyz123 schrieb:

naja, im prinzip kann man ja damit umgehen. im logfile steht ja drin wo.

Ich meinte mit "umgehen" nicht "notier's und mach weiter, als ob nichts passiert wäre", sondern "erkenne und behebe die Fehlerursache". Und imho sind solche Konstrukte nur während der Debug-Phase zu gebrauchen - aber dann bitte mit einem 'throw;' am Ende des catch-Blocks.

[xyz23]

ich meinte mit "umgehen" an z.b.:
das prog schickt das log nach hause, der fehler wird in der funktion gesucht, behoben, ein update gebaut das vom prog automatisch gezogen wird und der user weiß von nix.

wäre soch ein schöner ansatz

[ghorst]

@xyz123 es hat nachteile. so sind exceptions nicht gerade die schnellste methode und vor allem braucht man sie in c++ nicht immer fangen, wenn man sie nicht behandeln will/kann. macht den code nur unübersichtlich. setzt dann allerdings normalerweise voraus, dass man die resourcen per raii belegt hat, da diese dann einfach während des stack-unrolls wieder freigegeben werden.

fangen, in den logfile schreiben und weiterwerfen. kann man, wie es CStoll schon sagte, in der debug-phase gebrauchen. wenn du aber nichts weiter von hand aufzuräumen hast, brauchst du die exception auch nicht zu fangen.

achja: in ein catch(...) gehört in den meisten fällen ein throw; aus einem sehr einfachen grund: wenn du den fehler nicht kennst, kannst du ihn auch nicht sinnvoll behandeln...
ein programm nach einer unbekannten exception einfach weiterlaufen zu lassen, als wäre nichts passiert, ist naja mutig (man könnte auch wahnsinnig sagen, aber das mach ich besser nicht.)

[CStoll]

Du arbeitest nicht zufällig für MS?

Exceptions stehen für Ausnahmesituationen, die durch falsche Bedienung oder Systemstörungen auftreten können - und normalerweise sollte der Programmierer vor der Auslieferung wissen, wo solche Störungen auftreten können und wie er auf sie reagieren kann. Bugs solltest du beheben, während du in der Debug-Phase bist.

[LordJaxom]

xyz23 schrieb:

ich meinte mit "umgehen" an z.b.:
das prog schickt das log nach hause, der fehler wird in der funktion gesucht, behoben, ein update gebaut das vom prog automatisch gezogen wird und der user weiß von nix.

Damit implizierst Du, dass Exceptions nur bei Programmierfehlern auftreten können.

Gerade in C++ ist aber das nicht der Fall. Hier überlegt man sich dreimal, ob man einen Programmierfehler nicht schon zur Compilezeit abfangen kann (und das kann man viel häufiger als in Sprachen wie Java). Echte Logik-Exceptions sind dagegen äußerst selten.

Darüberhinaus kannst Du undefiniertes Verhalten (wenn in Java DisisionByZero, NullReference oder sonstige Exceptins fliegen) überhauptnicht fangen.

[asc]

CStoll schrieb:

... Bugs solltest du beheben, während du in der Debug-Phase bist.

Du hast es gut, scheinbar hast du noch nie in einen Projekt ala Bananensoftware (Software die beim Kunden reift) gesessen. Es ist immer schön wenn man einerseits gezwungen ist etliche Features einzubauen, anderseits die Software aber noch etliche Fehler hat, und das ganze mit Zeitdruck garniert. Und wenn der Chef sagt Feature a muss unbedingt raus, und er anderseits von den Fehlern weiß, so kommt es halt zu solcher Software.

cu André

[kennerdeszeugs]

asc schrieb:

CStoll schrieb:

... Bugs solltest du beheben, während du in der Debug-Phase bist.

Du hast es gut, scheinbar hast du noch nie in einen Projekt ala Bananensoftware (Software die beim Kunden reift) gesessen. Es ist immer schön wenn man einerseits gezwungen ist etliche Features einzubauen, anderseits die Software aber noch etliche Fehler hat, und das ganze mit Zeitdruck garniert. Und wenn der Chef sagt Feature a muss unbedingt raus, und er anderseits von den Fehlern weiß, so kommt es halt zu solcher Software.

[CStoll]

Bisher hatte ich noch das Glück, nicht unter Zeitdruck zu stehen (mal sehen, was die Zukunft bringt). Aber selbst wenn die Debug-Phase erst beim Kunden stattfindet, sollte nach einer Exception nicht einfach weitergemacht werden, als sei nichts passiert - entweder das Programm weiß selber, wie es auf einen Fehler reagieren kann oder es verabschiedet sich mit einer Information für den Anwender und/oder Entwickler (notfalls meldet es auch nur einen Fehler und setzt sich auf den letzten verwertbaren Status zurück).

[xyz123]

Wir reden nicht über Freeware. Der Kunde haut dich, wenn das Programm crasht. Egal ob 1x oder alle 10 min.

Egal... Wir waren ja bei try/catch
Wegen der Performance hatte ich gelesen, dass es da keine Probleme gibt. Und wegen dem weiterlaufen - hmmmmmm naja, lööft halt erstmal. Nach mir die ....

[ghorst]

es gibt keine geschwindgikeitsunterschiede, wenn du keine exceptions benutzt, aber dein programm mit solchen kompiliert hast. wenn du sie einbaust, aber nie wirfst, ist der unterschied minimal. wenn du sie allerdings wirfst, sind sie eher von der langsamen art.

was deine einstellung zum weiterlaufen angeht: ich wünsche dir viel spaß mit den fehlermeldungen deiner kunden, die dann plötzlich nicht reproduzierbar sind. das stört die kunden gemeinhin noch weit mehr als reproduzierbare abstürze, an die man sich gewöhnen kann...

[Simon2]

Also wenn es nur um die Information geht, ob eine Funktion mittels exception oder return beendet wurde, würde ich einfach eine "Scopeklasse" stricken:

struct ErrorLogger {
   bool err;
   string fktName;
   ErrorLogger(string const& name) : err(true), fktName(name) {}
   void clear() { err = false; }
   ~ErrorLogger() { if(err) writelog("Fehler in " + fktName); }
};

void blub
{
   ErrorLogger el("blub");
      ..nur hier code!
   el.clear();
}

Damit hat man eine zentrale Stelle für das Logging (die man auch zentral konfigurieren kann) und hat auch keine "Copy-Paste-Probleme" - einzig das Vergessen eines clear()-Calls kann einen erwischen ... aber das fällt schon im Gutfall-Test schnell auf.
KANN man machen (haben wir in Teilen unseres Programms auch)....

Gruß,

Simon2.

[kennerdeszeugs]

CStoll schrieb:

Bisher hatte ich noch das Glück, nicht unter Zeitdruck zu stehen (mal sehen, was die Zukunft bringt). Aber selbst wenn die Debug-Phase erst beim Kunden stattfindet, sollte nach einer Exception nicht einfach weitergemacht werden, als sei nichts passiert - entweder das Programm weiß selber, wie es auf einen Fehler reagieren kann oder es verabschiedet sich mit einer Information für den Anwender und/oder Entwickler (notfalls meldet es auch nur einen Fehler und setzt sich auf den letzten verwertbaren Status zurück).

Theoretisch ja. Aber bei manchen Plugin- oder Serveranwendungen ist es nicht immer so einfach eine Fehlermeldung irgendwo anzuzeigen. Und wenn bei einer Präsentation eine "Windows Fehlermeldung" kommt und sich das Programm verabschiedet, dann kommt das glaub ich um einiges schlechter, als eine Funktion die nichts macht, vorallem bei Programmen die eine Weile zum starten brauchen oder man eine ganze Weile arbeiten musste, bis man zu dieser Stelle kommt. Da ist es dem Kunden dann lieber, wenn das Plugin so "stabil" läuft, dass er seine Arbeit noch speichern und sich dann beschweren kann, als das seine Arbeit auf einen Schlag weg ist. Sowas sieht für den Kunden halt stabiler aus, als eine Anwendung die sich dauernd verabschiedet. Natürlich sollte man nicht überall alle exceptions fangen und dann planlos versuchen weiterzumachen. Am besten sollte man sie so platzieren, dass das Programm dann wieder in einem vernünftigen Zustand ist, was sicher nicht immer geht.

[CStoll]

xyz123 schrieb:

Wir reden nicht über Freeware. Der Kunde haut dich, wenn das Programm crasht. Egal ob 1x oder alle 10 min.

Deswegen sagte ich ja auch etwas von "auf letzten verwertbaren Status zurücksetzen"- wenn du nach dem Fehler einfach weitermachst, als wäre nichts passiert, ist das noch ärgerlicher als eine Nachricht "hier ist was kaputt" (vor allem wegen der möglichen Folgefehler).

Edit @Kenner: Sagte ich doch - man sollte dort auf einen Fehler reagieren, wo man damit umgehen kann. (und ein Teil-Reset der Anwendung auf den Zustand vor dem Fehler kann auch noch als "umgehen" durchgehen)

[xyz123]

Schade, dass ich die Sache jetzt so verteidige. Mags eigentlich auch überhaupt nicht - bin da halt aber so reingerutscht.

Noch mal kurz. Ich sagte nie, dass das Programm alle paar Sekunden eine Exception wirft. Überhaupt nicht. (Ich auch können C++ )
Es geht einfach nur darum wie ihr es findet auf diese Art und Weise Fehler abzufangen, auch wenn sie nur einmal im Monat auftreten. Oder Woche, was auch immer. Nicht! ständig...