Was genau bringen exceptions?

CStoll schrieb:

(obwohl es mich mal interessieren würde, warum man in Java nicht auf OutOfMemory-Fehler reagieren kann)

Kann man schon. Die Dokumentation sagt zu Errors:

An Error is a subclass of Throwable that indicates serious problems that a reasonable application should not try to catch.

Das Problem ist klar: Wenn man schon keinen Speicher mehr hat, dann ist es nicht unwahrscheinlich, dass das Fangen dieses Fehlers und die Reaktion darauf wieder einen solchen Fehler provoziert. Allerdings sollte man in main() unten eigentlich ganz gute Chancen haben, dass der Speicher wieder reicht um noch etwas ins logfile zu schreiben. An Ort und Stelle einen solchen Fehler zu fangen will zumindest gut durchdacht sein.

CStoll schrieb:

Aber Ford's Aussage war alles andere als klar formuliert und wurde (imho) von Artchi genauer erläutert.

Hm.

Ford Perfect schrieb:

wenn ich in Java ne exception werf, dann muss ich sie auch fangen, sonst gibts nen compileerror, wenns keine runtimeexception ist.

Artchi schrieb:

Stimmt doch garnicht! Java-Exceptions die von RuntimeException abgeleitet sind, müssen nicht abgefangen werden!

Also für meine Begriffe hat der anonyme Assi seinen (korrekten) Punkt bereits ausreichend klar formuliert. Für die Sonderschüler unter uns kann man natürlich den Satz noch einmal neu (und rückwärts) formulieren. Das "Stimmt doch garnicht!" war in jedem Fall unangebracht, von den nachfolgenden echten Beleidigungen ganz zu schweigen.

Die Bemerkung "Lern lesen!" an sich ist noch keine Beleidigung, aber zumindest in der Form grob unhöflich.

Ansichtssache. Tatsache ist, Artchi hat Müll geschrieben, weil er nicht richtig gelesen hat oder weil er nicht richtig lesen kann.

Was hast du dann für einen Grund, dich hier einzumischen?

Ich fühle mich dem Kollektiv der anonymen Assis zugehörig.

Simon2

CStoll schrieb:

...@Simon: Imho wäre Artchi derjenige gewesen, der auf diese Bemerkung reagieren müsste

Mag sein, aber Du musst wissen, dass ich mein Rittername "Rächer der Witwen und Enterbten" lautet.

Gruß,

Simon2.

Simon2

anonymer assi schrieb:

...Sonderschüler... ...Artchi hat Müll geschrieben ...weil er nicht richtig lesen kann....

Ganz klar nur herabsetzend gemeint und in keinster Weise sachlich richtig oder der Diskussion förderlich => Beleidigung (und sei sie noch so feinsprachlich verpackt), mit der der "Kontrahent" verunglimpft und damit die eigene Position gestützt werden soll.

Gruß,

Simon2.

Baracke

Die zwei "liebenden" Java und C++ haben sich mal wieder gefunden. Ich mag eigentlich Threads sehr gerne die beide behandeln, weil man eine Menge davon lernen kann. Der einzige Nachteil ist, das sie eigentlich immer eskalieren und da frag ich mich jedes mal warum? Ist doch nur ein Werkzeug, mag sein das einer den Schraubenschlüssel von der Firma besser findet als von der anderen aber im Endeffekt ist es wie Jacke und Hose.
Wie auch immer, kann sein das ich das falsch interpretiert habe doch hat "Ford Perfect" nicht damit angefangen Java in die C++ Welt zu werfen? Ich hab nichts gegen Java, ganz im Gegenteil da ich mir damit meine Bortkrümmel verdiene. Und C++ ist ehrer ein altes Hobby von mir (Ja ich war einer der Spieleprogrammierer die es wie Sand am Meer gab). Doch ich werde es tunlichst vermeiden das eine besser hinzustellen, wozu auch das bringt nichts als ewiges hin und her für so ziemlich nichts ausser gestressten Nerven (irgendwann auch Immunität gegen dergleichen ^^)

Zu dem Geflamme an sich stimme ich Simon2 voll und ganz zu

----------------------------------------------------------------------------------

Bei dem Thema an sich brauch ich nicht mehr viel sagen da meine Voreder schon ihre Arbeit vollbracht haben. Doch will ich einfach nur den Gedanken weitergeben mit dem ich am Anfang am meisten anfangen konnte.

Nehmen wir mal an du hast eine Methode die eine Klasse (Referenz) als Rückgabetyp hat welche sie aus Daten einer Datei erstellt. Die einzige Möglichkeit ist nun "null" zurückzugeben wenn ein Fehler auftritt oder der Klasse Fehlerzustände zu geben was nun wirklich nicht die schöne Art ist.
Doch was machen wir wenn der Fehler mehrere Ursachen haben könnte, wie von "Datei nicht gefunden" bis "Parsingfehler"?
Wie können wir sowas behandeln wenn wir keine Exception haben und dennoch Wert auf gutes Design legen? Es ist schwer, sehr schwer um nicht zu sagen fast unmöglich. Es wäre zwar durchaus auch noch möglich der Funktion an sich noch eine Fehlerklasse mitzugeben die den Fehler dann hält doch läuft es auf Exception heraus, nur komplizierter.
Doch die Exception geben uns eine einfache Möglichkeit mit diesem Problem umzugehen. Wenn die Datei nicht gefunden worden ist, wissen wir vielleicht von einer Default Datei als Ersatz? Oder bei einem Parsingfehler können wir die falsche Zeile zurücklieferen wo der Parser meint "ne du lass mal stecken den Mist".

Man könnte ganze Bücher vollschreiben über das Thema, was ja einige getan haben, jedoch bin ich nicht grade der Wanderer von nebenan in dem Gebiet

Hoff ich konnt dir ein wenig helfen und ein wenig interrese wecken
Die blubbende Baracke

PS: Alle Rechtschreibfehler sind beabsichtigt und dienen der allgemeinen Belustigung

PS2: Uiui ich sollte schneller schreiben und nicht so rumdümpeln, gehört auf die 3te Seite nach den 2 Posts von "Anonymer Assi"

CStoll

@"assi": Mit deiner letzten Bemerkung hast du endgültig den letzten Rest Achtung bei mir verspielt.
(OK, Ford und Artchi haben etwas aneinander vorbeigeredet, aber wie gesagt sollen sie das unter sich ausmachen - da hast du dich nicht reinzumengen)

@Simon: Das muß mir entgangen sein Trotzdem denke ich mal, daß Artchi sehr gut für sich selber sprechen kann (der Rest siehe oben).

@Baracke: Ja, Java vs. C++ ist immer wieder schön. Weniger schön ist es, wenn sich die Leute gegenseitig Beleidigungen an den Kopf werfen (und hier hatte der Flame-War noch nicht einmal etwas mit der Hass-Liebe zwischen Java und C++ zu tun).

(und zuletzt an meine Kollegen - es wäre sicher angebracht, den Thread auseinenderzudröseln, bevor man das eigentliche Thema nicht mehr wiederfindet ;))

CStoll schrieb:

@"assi": Mit deiner letzten Bemerkung hast du endgültig den letzten Rest Achtung bei mir verspielt.

Entschuldige, ich bin ein bisschen schwer von Begriff. Welche Bemerkung meinst du genau?

Ich fühle mich dem Kollektiv der anonymen Assis zugehörig.

?

CStoll

Ich meinte den kompletten Beitrag (besonders die Stellen, die Simon schon herausgehoben hat).

Dieser Hinweis gilt immer noch und AUCH für dich:

CStoll schrieb:

Ich bin zwar hier nicht zuständig, aber trotzdem: Könntet ihr bitte aufhören, euch gegenseitig Beleidigungen an den Kopf zu werfen? (und das gilt für ALLE Anwesenden)

hallo,
ich bin zwar weder "fordperfect" noch "anonymer assi", aber recht haben sie trotzdem. ihr (artchi, simon) spielt euch hier echt auf, das ist unglaublich.
jedesmal wenn ich in diesem forum rumstöbere muss ich sowas wie in diesem thread lesen, von euch und von anderen. da vergeht einem wirklich die lust sich in so einem forum anzumelden wenn sich selbst user mit mehreren tausend beiträgen so aufführen. da bleib ich lieber auch ein "anonymer assi" hier. das ist aber kein grund mich verarschen zu lassen.
und dat geilste is auch noch dass auf der startseite mit 900.000 von solchen postings das forum beworben wird

Artchi

Jester schrieb:

Behandelst Du Leute die Du nicht kennst also grundsätzlich respektlos? "Wenn ich jemanden nicht kenne ist er nicht richtig menschlich" klingt für mich ein bißchen nach Autismus.

NEIN! Verdrehe bitte nicht meine Aussagen. Mir geht es um das Internet/Web. Und genau diese Situation das ebend jeder, ohne sich kenntlich zu machen (körperliche Anwesenheit, über Stimme am Telefon usw.), einfach Mist bauen kann und darf. Es ist ja nun nicht so, das mir jemand in der Stadt entgegen kommt den ich nicht kenne und ich ihn nicht respektiere. Davon spreche ich doch nicht. Aber jeder kann aus der dunkelsten Ecke hier als unbekannter Feigling Porno-Links posten. Jeder kann mich beleidigen. Die Frage ist: würde er das machen, wenn er vor mir stehen würde??? (auch wenn ich ihn nicht kenne!) Nein! Würde er ebend nicht.

Es ist hier eine virtuelle Welt, falls es noch nicht jedem aufgefallen ist. Und nicht die reale Welt. Ich habe zu einem anonymen Poster keine "Beziehungspunkt". Verstehste jetzt was ich sagen will?

Forumsmitglieder wie GPC, CStoll u.a. sind hier sogar mit Foto im Forums-Magazin vertreten. Auch ich! Und wenn ich etwas sage, was vielleicht mal daneben ist (wovon ich mich nicht freisprechen kann), dann stehe ich mit meinem Realname wenigsten dafür gerade.

Ich habe irgendwann bewusst meinen "Status" als registrierter Benutzer aufgegeben nachdem mir "aufgefallen" war, daß die meisten thematisch interessanten Themen hier in "Ich hab aber doch Recht"-diskussionen ausarten.

Mir fällt es leichter mich von solchen Themen zu lösen wenn sie _nicht_ mit "meinem" Namen verbunden sind...

Artchi schrieb:

Aber jeder kann aus der dunkelsten Ecke hier als unbekannter Feigling Porno-Links posten.

Porno-Links?? Wo denn?
Sind Registrierte denn bessere Porno-Links-Poster? Hier klicken!

Jeder kann mich beleidigen.

Du verwechselst da was. Du warst der, der beleidigt hat. Von deinem elitären Gehabe ganz zu schweigen.

Die Frage ist: würde er das machen, wenn er vor mir stehen würde??? (auch wenn ich ihn nicht kenne!) Nein! Würde er ebend nicht.

Man kann viel behaupten, wenn der Tag lang ist. Du hast doch nicht die geringste Ahnung, wie derjenige sich Angesicht zu Angesicht verhalten würde.

Artchi

@all! Man sollte wieder ontopic werden.

Es ist jedenfalls nicht richtig, das Exceptions in C++ nicht richtig unterstützt werden, nur weil man nicht gezwungen wird, die explizit mit einem try-catch abzufangen. Das ganze hat auch Designgründe, die jeder in den Mailings des C++-Komitees nachlesen kann. Auch Herb Sutter hat sich schon mal in seinem Blog dazu geäussert. Excpetions in C++ arbeiten und funktionieren. Designentscheidungen als unfunktionstüchtig abzuwerten und zu sagen, in Sprache X sind sie deshalb besser, ist einfach unbegründet.

tntnet

Hi,

ich wollte auch mal was zum Thema sagen (und nicht zum Flame).

Simon2 hat ein sehr gutes Beispiel gemacht, wo Exceptions den Code vereinfachen. Mann kann dem Algorithmus besser folgen, wenn er nicht durch permanente Fehlerabfragen unterbrochen wird.

Beispiel ohne Exceptions:

int f()
{
  int ret;
  ret = f1();
  if (ret != 0)
    return ret;
  ret = f2();
  if (ret != 0)
    return ret;
  ret = f3();
  if (ret != 0)
    return ret;
}

Das gleiche mit Exceptions:

void f()
{
  f1();
  f2();
  f3();
}

Ich nehme einfach mal an, die Funktion f führte einen Algorithmus, bestehend aus 3 Unterfunktionen. Im Fehlerfall einer Unterfunktion soll der Fehler einfach nur weiter gereicht werden. Ich denke, die Funktion mit Exceptions ist wesentlich übersichtlicher.

Und noch ein Kommentar zu Java vs. C++:

Java verlangt, daß eine Methode an der Schnittstelle die Exceptions, die es auslöst auch bekannt gibt. Das klingt gut und hat seine Vorteile. Der Benutzer der Schnittstelle weiß, welche Fehlerzustände geliefert werden können, wenn er nur die Schnittstelle sieht.

Die Kehrseite ist, daß ich beispielsweise in abgeleiteten Klassen, die Methoden überschreiben, keine neuen Fehlerzustände einführen kann. Man stelle sich eine Klasse mit einr Getter-Methode vor. Diese wirft keine Exception. In einer abgeleiteten Klasse überschreibe ich die Methode, um den Wert beispielsweise aus einer Datenbank zu lesen. Was mache ich dann bei Datenbankfehlern? Bei Java habe ich dann ein Problem, da mir die Methodensignatur der Basisklasse verbietet, Fehler zu melden.

Ich hoffe, das war neutral genug formuliert, so daß ich keinen Brennstoff für weitere Flames gegeben habe. Welche Technologie ich bevorzuge, sieht man spätestens in meiner Signatur.

Tntnet

THX 1138

Irgendwie erinnert mich der Ausdruck "Lern lesen!" an etwas...http://www.zfx.info/DisplayThread.php?TID=3723
@Artchi: Bin nicht der Meinung, dass Registrierte automatisch zu Persönlichkeiten werden, man nehme mich als Beispiel. Du weisst nichts von mir, hab ich deswegen mehr Respekt verdient als ein Unreg? Nur mal als Denkanstoss.

@Topic:
Nur weil man nicht gezwungen wird, Exceptions zu fangen, sind sie nicht schlecht. Es zwingt dich auch niemand Klassen zu verwenden, oder Templates. Aber sie sind verfügbar und ein gewissenhafter Programierer wird sie einsetzen, wo sinnvoll und nötig. In Java wird man gezwungen zu gewissen Sachen, das nimmt einem aber ab zu denken. Ob das gut ist lass ich mal offen.

Baracke

Hm, ich sollte es sein lassen aber hab grad nichts zu tun.

@CStoll: Ich will dich nicht nerven oder so, aber hat der "Ford Perfect" mit seinem Java-Einwurf nicht die Sache ins Rollen gebracht. Deswegen hab ich die alte gute Java und C++ Liebe herangezogen, da dort immer ein "wenig" übertrieben wird. Sei es beim peinlichsten finden von Fehlern (sogar Rechtschreibfehler werden dann wichtig um Thesen zu wiederlegen ) oder darlegen von Features mit praxisfremden Beispielen.

@anderer anonymer: Ich weiss nicht was du hast, die Beiträge sind fast immer fachlich korrekt. Und falls du länger in dem Forum stöberst findest du richtige Diamantensplitter an kurzer und prägnanter Form, welche ich in so machen Forum misse.
Es ist natürlich dir überlassen was du wie findest, jedoch musst du auch bedenken das alle die hier regelmässig Posten vorbelastet sind. Da die meisten Flames die du hier lesen kannst von unregestrieten ins Rollen gebracht wurden. Das Ding ist ja leider, es macht machen es regelrecht spass die Fehler von anderen möglichst provozierend zu berichtigen. Das ohne Mimik ist der Tot für jeden Thread mit einem Thema ausser Flame

In dem Sinne, eine Stimme für ausseinanderbröckeln.
Wählende Baracke

PS: Werd nimma in den Thread posten, versprochen (Wehe ihr fang jetzt an über mich herzuziehen ^^).

CStoll

Baracke schrieb:

@CStoll: Ich will dich nicht nerven oder so, aber hat der "Ford Perfect" mit seinem Java-Einwurf nicht die Sache ins Rollen gebracht. Deswegen hab ich die alte gute Java und C++ Liebe herangezogen, da dort immer ein "wenig" übertrieben wird. Sei es beim peinlichsten finden von Fehlern (sogar Rechtschreibfehler werden dann wichtig um Thesen zu wiederlegen ) oder darlegen von Features mit praxisfremden Beispielen.

Möglich, daß "Java" der Auslöser ist, aber der ganze Flame-War hat inzwischen herzlich wenig damit zu tun (und daran sind leider nicht nur die Unregs schuld).

anderer anonymer schrieb:

hallo,
ich bin zwar weder "fordperfect" noch "anonymer assi", aber recht haben sie trotzdem. ihr (artchi, simon) spielt euch hier echt auf, das ist unglaublich.
jedesmal wenn ich in diesem forum rumstöbere muss ich sowas wie in diesem thread lesen, von euch und von anderen. da vergeht einem wirklich die lust sich in so einem forum anzumelden wenn sich selbst user mit mehreren tausend beiträgen so aufführen. da bleib ich lieber auch ein "anonymer assi" hier. das ist aber kein grund mich verarschen zu lassen.
und dat geilste is auch noch dass auf der startseite mit 900.000 von solchen postings das forum beworben wird

Von diesen 900.000 Beiträgen ist vielleicht ein verschwindend geringer Anteil, wo sich jemand "aufspielt" - und meistens sind das Antworten auf (sorry) RTFM-Fragen. Der Anteil an Troll-Postings von Unregistrierten ist da um einiges höher.

Artchi

tntnet schrieb:

Simon2 hat ein sehr gutes Beispiel gemacht, wo Exceptions den Code vereinfachen. Mann kann dem Algorithmus besser folgen, wenn er nicht durch permanente Fehlerabfragen unterbrochen wird.

Beispiel ohne Exceptions:
int f()
{
  int ret;
  ret = f1();
  if (ret != 0)
    return ret;
  ret = f2();
  if (ret != 0)
    return ret;
  ret = f3();
  if (ret != 0)
    return ret;
}

Hinzu kommt ja, das f1, f2 und f3 zwar einen Fehlercode 1 liefern können, aber diese total unterschiedliche Bedeutung haben können. Also wenn f eine 1 zurück liefert, weiß der f-Aufrufer absolut nicht, was nun passiert ist.

Das gleiche mit Exceptions:
void f()
{
  f1();
  f2();
  f3();
}

Mit Exceptions habe ich typisierte Fehler. Und ich bekomme als f-Aufrufer diesen einen bestimmten Typ zurück, und ich kann entsprechend "typisiert" reagieren. Genial!

Java verlangt, daß eine Methode an der Schnittstelle die Exceptions, die es auslöst auch bekannt gibt. Das klingt gut und hat seine Vorteile. Der Benutzer der Schnittstelle weiß, welche Fehlerzustände geliefert werden können, wenn er nur die Schnittstelle sieht.

Das kannst du aber auch in C++ an der Schnittstelle erkennen. Vorausgesetzt, es wurde auch entsprechend definiert. Leider macht das so gut wie niemand, was ich sehr schade finde. Ich selbst mache das in meinem Code, das ich in der Schnittstelle schreibe, was geworfen werden kann:

void foo() throw (std::invalid_argument);

LEIDER bringt MSVC hier immer eine Warnung, die ich dann mit einem pragma ausschalte. Wie es bei anderen Compilern aussieht, weiß ich leider nicht.

Simon2

Artchi schrieb:

...

Java verlangt, daß eine Methode an der Schnittstelle die Exceptions, die es auslöst auch bekannt gibt. Das klingt gut und hat seine Vorteile. Der Benutzer der Schnittstelle weiß, welche Fehlerzustände geliefert werden können, wenn er nur die Schnittstelle sieht.

Das kannst du aber auch in C++ an der Schnittstelle erkennen. Vorausgesetzt, es wurde auch entsprechend definiert. Leider macht das so gut wie niemand, was ich sehr schade finde. ...

Hi,

ich bin einer von denen, die es absichtlich nicht machen (und sich damit an einen Rat von Herb Sutter halten). Für mich ist das größte Problem mit C++'s exceptions (und ein großer Vorteil bei Java), dass Verletzungen der exception specification erst zur Laufzeit ausgewertet werden. Eigentlich sind sie aber Mittel, die ich in der Designphase brauche und nicht erst beim Integrationstest.

Ich verstehe zwar, dass man "damals" C-Kompatibilität gesucht, aber nicht, wieso man damals nicht einfach alle C-Funktionen (bzw. jede Funktion ohne excep-spec) als "throw()" definiert hat. In C kann man ja schließlich auch keine werfen und C-Wrapper für C++-Code muss man sowieso entsprechend implementieren (weil man auch in C keine fangen kann)....

Gruß,

Simon2.

P.S.: Von MS habe ich nur den VC6 und der ignoriert excep-spec komplett ! (auch zur Laufzeit)

tntnet

Schön, daß wir wieder beim Thema sind

Ich finde Exceptions auch genial. Ich habe allerdings das Gefühl, ihr habt meine 2 Ausführung nicht verstanden.

Die Throw-Specifications finde ich persönlich unnötig und störend. Eine Basisklasse kann verhindern, daß eine abgeleitete Klasse überhaupt Fehler melden darf. Fehlerbehandlung ist doch eins der wichtigsten Dinge, wenn nicht das wichtigste überhaupt, für robuste Programme. Wenn ich eine Methode entwickele, muß ich immer die Möglichkeit haben, einfach auf Fehler zu reagieren. Sonst ist die Versuchung zu groß, darauf zu verzichten.

Ich will meine Ausführung von vorhin nochmals an einem Beispiel erläutern.

Man nehme eine Basisklasse:

class MyBusinessObject
{
    std::string attribute1;
  public:
    virtual const std::string& getAttribute1() const throw()
    { return attribute1; }
    virtual void setAttribute1(const std::string& a)
    { attribute1 = a; }
};

Hier habe ich ein Business-Objekt deklariert und mit einer default Implementierung einer Methode. Später bemerke ich, daß die Methode selten benötigt wird aber das füllen des Attributes viel Zeit in anspruch nimmt. Daher entscheide ich mich für Lazy-Init, bei dem das Attribut erst gefüllt wird, wenn es benötigt wird. Die neue Methode liest den Wert aus der Datenbank (oder holt sich das per RPC-Request oder was auch immer):

class MyLazyBusinessObject : public MyBusinessObject
{
  public:
    virtual const std::string& getAttribute1() const throw()
    {
       if (MyBusinessObject::getAttribute1().empty())
       {
          try
          {
            setAttribute1(
              db.selectValue("select attribute1 from table where ..."));
          }
          catch (const myDbException& e)
          {
             // dieser catch ist notwendig, da selectValue eine Exception auslösen könnte
             // aber was zum Teufel mache ich jetzt mit meinem Fehler??? :rage: :warning:
          }
       }
       return MyBusinessObject::getAttribute1();
    }
}

Hier bleibt mir nichts anderes übrig, als den Fehler zu ignorieren, was tödlich ist.

Wenn ich ein System designe, gehe ich davon aus, daß alles eine Exception werfen kann. In meinem Tntnet beispielsweise fange ich alle Exceptions auf, die die Komponente nicht selbst verarbeitet hat. Entweder ist sie von tnt::HttpError abgeleitet - dann habe ich einen HTTP-Fehlercode - oder von std::exception. Dann kommt ein HTTP-Fehler 500 - internal Server error.

Die Einschränkung, die ich grundsätzlich mache ist, daß jede Exception direkt oder indirekt von std::exception abgeleitet sein muß. Selbst das könnte man mit catch(...) aufweichen ( sollte ich vielleicht ergänzen ).

Für robuste Programme ist es unbedingt notwendig, daß alle Fehler beachtet werden. Und das kann ich nur garantieren, wenn es einfach ist, auf Fehler zu reagieren.

Tntnet