C++ frequently questioned answers

Shade Of Mine schrieb:

Release funktionen dürfen in keiner sprache fehler produzieren...

das ist doch keine frage der sprache. eine release-funktion, die nur eine statusvariable setzt, wird mit einer wahrscheinlichkeit von 0.999... immer klappen. aber bei einer, die z.b. was über eine netzwerkverbinung schicken muss, dann diese verbindung schliessen muss, etc. sieht's schon schlechter aus. hierbei stellt sich die frage, welchen reellen gebrauchswert destruktoren in solchen fällen haben. eine programmiersprache sollte dem benutzer eigentlich nicht aufzwingen, wie er release-funktionen zu bauen hat.

ready_sep15-r115-1_7.txt;20;30

Shade Of Mine schrieb:

Release funktionen dürfen in kaum einer sprache fehler produzieren...
siehe zB free()

char *p = malloc(1);
free (p+123); // <--- huch?

Shade Of Mine

Stell dich nicht dümmer an als du bist.

Natürlich kann alles fehlschlagen, es geht um einen direkten Hinweis dass es fehlgeschlagen ist. free returned void, ergo kannst du Fehler von free nicht abfangen. Selbiges bei Destruktoren, Finalizern, etc.

Natürlich gibt es 100.000 möglichkeiten solche fehler dennoch zu reporten, aber eben nicht über den Standard weg - was bedeutet dass ein dtor was den client code betrifft immer erfolgreich ist - dh, wir können rollbacks machen.

wenn dennoch ein fehler auftritt muss sich anderer code damit rumschlagen.

das ist in jeder sprache die ich kenne so. nur wenn man das mal direkt sagt, drehen alle leute durch. in sprachen wie java wo jede close methode was werfen kann - was macht man dort? richtig, überall try{f.close();}catch(Exception e){} gemacht. Und warum? Weil man kann auf 99% der Fehler eh nicht reagieren.

Was soll ich denn machen wenn die Datei nicht schließbar ist? Ich kann den Fehler loggen, aber sonst? Was soll ich denn tun? Und genau das ist die Situation in 99% der Fälle.

Shade Of Mine schrieb:

Natürlich kann alles fehlschlagen...

das sag ich doch.

Shade Of Mine schrieb:

das ist in jeder sprache die ich kenne so. nur wenn man das mal direkt sagt, drehen alle leute durch. in sprachen wie java wo jede close methode was werfen kann - was macht man dort? richtig, überall try{f.close();}catch(Exception e){} gemacht. Und warum? Weil man kann auf 99% der Fehler eh nicht reagieren.

wie kommst du darauf, dass man auf 99%??! der fehler nicht reagieren kann? ob und wie fehler behandelt werden, ist extrem situationsabhängig. und sehr oft gibt es sogar mehrere möglichkeiten, was sinnvoles zu tun.

Shade Of Mine schrieb:

Was soll ich denn machen wenn die Datei nicht schließbar ist? Ich kann den Fehler loggen, aber sonst? Was soll ich denn tun? Und genau das ist die Situation in 99% der Fälle.

z.b. ist es in dem fall wichtig, herauszufinden warum die datei nicht schliessbar ist. hat jemand das speichermedium entfernt? ist das filesystem korrupt? sind systemressourcen momentan knapp, so dass das schliessen der datei um ein paar sekündchen vertagt werden sollte? usw.. davon abhängig gibt es verschiedene lösungswege.

Shade Of Mine

~fricky schrieb:

wie kommst du darauf, dass man auf 99%??! der fehler nicht reagieren kann? ob und wie fehler behandelt werden, ist extrem situationsabhängig. und sehr oft gibt es sogar mehrere möglichkeiten, was sinnvoles zu tun.

Sag mal, magst du nicht mitdenken oder willst du nur rumtrollen?

Es geht nicht um alle Fehler sondern um Release also Freigabe Fehler.

Wie reagierst du auf ein Fehlschlagen von close(), free(), disconnect(),...?

Garnicht. Es gibt genau 3 mögliche Ansätze:

Fehler loggen und weiter
forced shutdown der resource probieren (je nach resource ist das möglich oder nicht)
bestimmte zeit warten und nochmal probieren

Aber da dir das alles entweder zu hoch ist oder du nur trollen willst war das mein letzter Post diesbezüglich.

PS:
oder schreibst du bei jedem flcose, free, etc. immer 100+ Zeilen fehlerbehandlungslogik dazu?

Es ist ja nicht so dass ein dtor nicht mitteilen kann dass er fehlgeschlagen ist... das kann er ja ruhig machen, nur eine exception darf er nicht werfen.

tfa

~fricky schrieb:

z.b. ist es in dem fall wichtig, herauszufinden warum die datei nicht schliessbar ist. hat jemand das speichermedium entfernt? ist das filesystem korrupt? sind systemressourcen momentan knapp, so dass das schliessen der datei um ein paar sekündchen vertagt werden sollte? usw.. davon abhängig gibt es verschiedene lösungswege.

Welche Wege? Man lässt einen Fehlerdialog aufpoppen (wahlweise ein Server-Log) wo drinsteht "Datei xy kann nicht geschlossen werden. hat jemand das speichermedium entfernt? ist das filesystem korrupt? sind systemressourcen momentan knapp?"

Shade Of Mine schrieb:

so dass ein dtor nicht mitteilen kann dass er fehlgeschlagen ist... das kann er ja ruhig machen, nur eine exception darf er nicht werfen.

und das geht wie? soll etwa erfolg/misserfolg in einer variablen gespeichert werden, die später abgefragt werden soll? einer der hauptgründe für die existenz von exceptions ist doch, daß man keine rückgabewerte abzufragen braucht. ich kann mir kaum vorstellen, dass das abfragen einer statusvariablen nach 'delete' so viel besser ist.

tfa schrieb:

Welche Wege? Man lässt einen Fehlerdialog aufpoppen (wahlweise ein Server-Log) wo drinsteht "Datei xy kann nicht geschlossen werden. hat jemand das speichermedium entfernt? ist das filesystem korrupt? sind systemressourcen momentan knapp?"

na, verschiedene massnahmen sind denkbar wie z.b. das:
- speicherkarte entfernt: nicht weiter schlimm, aber letzte datei als ungeschrieben betrachten. mit dem anlegen neuer files warten, bis wieder eine karte drin ist, dann vorherige datei nochmal schreiben.
- filesystem korrupt: extrem schlimm. sofort aufhören dateien zu schreiben und warnmeldungen (wie auch immer) ausgeben. bei 'nem exklusiven medium eventuell reparaturmassnahmen versuchen.
- temporärer resourcen-engpass: nicht weiter schlimm. aktion in einer warteschlange puffern und etwas besonnener weitermachen. zum ernsthaften problem wirds erst wenn die queue voll läuft.

Shade Of Mine

so das ist jetzt aber der letzte post:

fricky, wie oft hast du 100+ Zeilen fehlerbehandlung für ein fehlgeschlagenes fclose()?
Null mal. NIE. Keine Chance.

Und genau das ist der Punkt. Man reagiert bei sowas mit signalen.

Das Problem an Exceptions ist, dass man sie nicht rückgängig machen kann. Sprich: es tritt ein "Fehler" auf der aber kein wirklicher Fehler ist. Ich kann die Exception nicht im nachhinein ignorieren, sie hat bereits massig code ausgeführt. Hier sind signale viel besser - da ich signale ignorieren kann (oder auch nicht).

Aber das ganze ist sowas von praktisch irrelevant. wenn ein fclose fehlt schlägt ist mir das egal. wenn es eine wichtige resource ist dann garantiere ich irgendwie dass die writes erfolgreich sind. denn es geht um die reads/writes nicht um die open/closes.

deshalb nochmal:
niemand überprüft printf auf erfolg oder fclose oder free (haha, free kann man garnicht prüfen). weil es in 99% der fälle keinen Sinn macht und wenn man es dann doch brauchen sollte, gibt es massig möglichkeiten und nein error flags sind nicht die lösung hier.

es macht keinen sinn immer und überall 100.000 zeilen code fehlerbehandlung zu schreiben. und exception in release funktionen produzieren das aber. denn ich kann plötzlich nicht 2 resourcen gleichzeitig releasen. ich brauche plötzlich massig try/catch blöcke für jedes release. das ist in keiner sprache praktikabel. deshalb ist das hier so wahnsinnig lächerlich...

Shade Of Mine schrieb:

deshalb ist das hier so wahnsinnig lächerlich...

so ist es. vor allem dein letztes posting, mit dem du verzweifelt versuchst, durch weitere haltlose behauptungen deine 'in-99%-der-fälle-kann-man-nix-machen' theorie zu begründen. also, lassen wir's hiermit einfach gut sein.