Wozu exception handling?

TNA

Ich muss auch sagen dass Exeptions sehr hilfreich sein können aber auf der anderen Seite auch eine Menge an Arbeit erzeugen und hin und wieder fühlt man sich sogar genötigt, recht unschönen Code zu schreiben damit das ganze Exeption save ist. Manchmal frage ich mich auch, ob es das wert ist.

SeppJ

TNA schrieb:

Ich muss auch sagen dass Exeptions sehr hilfreich sein können aber auf der anderen Seite auch eine Menge an Arbeit erzeugen und hin und wieder fühlt man sich sogar genötigt, recht unschönen Code zu schreiben damit das ganze Exeption save ist. Manchmal frage ich mich auch, ob es das wert ist.

Wenn du durch Exceptions bereits viel Arbeit und unschönen Code erzeugst, wie sähe denn erst dann der gleiche Code mit klassischen Fehlercodes aus?

TyRoXx

Mein Eindruck ist, dass Ausnahme-sicherer Code in der Regel kürzer ist als welcher, der nicht sicher ist.
Und im Gegensatz zu Java oder C# sieht man in C++ fast nie ein try , weil es den Destruktor gibt. Da der Destruktor auch ohne Ausnahmen ein unbezahlbares Hilfsmittel gegen Lecks aller Art ist, sollte man ihn unbedingt benutzen. Mit etwas Sachverstand bekommt man dann Ausnahmesicherheit kostenlos dazu.
Ausnahmen sind das sinnvollste Mittel zur Fehlerbehandlung in C++. Rückgabewerte wie in C sind viel zu umständlich und fehleranfällig. Schaut euch mal gute C-Programme an, die viele Ressourcen verwalten. Da entfällt schnell mal die Hälfte aller Statements auf Fehlerbehandlung.

Marthog

TyRoXx schrieb:

Mein Eindruck ist, dass Ausnahme-sicherer Code in der Regel kürzer ist als welcher, der nicht sicher ist.

foo(std::unique_ptr<IrgendEineKlasse>(new IrgendEineKlasse))

ist nunmal länger als

foo(new IrgendEineKlasse);

TyRoXx

Marthog schrieb:

TyRoXx schrieb:

Mein Eindruck ist, dass Ausnahme-sicherer Code in der Regel kürzer ist als welcher, der nicht sicher ist.
foo(std::unique_ptr<IrgendEineKlasse>(new IrgendEineKlasse))
ist nunmal länger als
foo(new IrgendEineKlasse);

Das ist kein Java. Die Leute wissen, dass es in C++ delete gibt.
Da wird also noch an mindestens einer Stelle so ein Müll stehen wie:

if (p)
{
	delete p;
	p = NULL;
}

Sogar eher an mehreren Stellen pro new .
Das ist dann deutlich länger als richtiges C++.

Außerdem ist die Länge eines einzigen Ausdrucks nicht so entscheidend. Ich meinte eher die Länge von Funktionen bzw die Anzahl der Statements.

dot

Abgesehen davon:

Marthog schrieb:

foo(std::unique_ptr<IrgendEineKlasse>(new IrgendEineKlasse))

Ist nicht exception-safe...

Edit: Ok, in dem konkreten Beispiel isses in der Regel wohl ok.

foo(std::unique_ptr<IrgendEineKlasse>(new IrgendEineKlasse), std::unique_ptr<IrgendEineAndereKlasse>(new IrgendEineAndereKlasse))

wär aber schon nimmer ok...

Nexus

Marthog schrieb:

foo(std::unique_ptr<IrgendEineKlasse>(new IrgendEineKlasse))

Darum wird C++14 auch std::make_unique() haben.

foo(std::make_unique<IrgendEineKlasse>())

Ist exceptionsicher, vermeidet die doppelte Benennung des Typen und bringt new endgültig aus dem Anwendercode.

hustbaer

nwp3 schrieb:

Anders ausgedrückt: Wenn in einer Ausnahmesituation ein Resourcenleck entsteht ist das völlig in Ordnung. Wenn diese Situation so häufig vorkommt, dass die Resourcen knapp werden, dann war das keine Ausnahmesituation und Exceptions wurden falsch benutzt und (...)

Falsch.
Begründung: z.B. das was audacia geschrieben hat. Bzw. wenn du 1-2 Minuten googelst wirst du "Milliarden und Abermilliarden" von Diskussionen zu dem Thema finden, wo die ganzen alten Argumente durchgekaut werden.

Bzw. warum Exceptions genau nicht nur für das da sind was du beschreibst, beantwortest du dir ja selbst, indem du feststellst dass sie dann sinnlos wären.

Exception != Fatal-Error. Exception = Ausnahmesituation. Ausnahmesituation = nicht der Regelfall. Nicht der Regelfall != kommt nie vor. Case closed.

floorball

chaos7568568 schrieb:

ihr HU*ENSO*HNE!!!

was zum geier bedeutet UB!!!

Unter-belichted

Marthog

Undefined Behaviour - Der Standard lässt offen, was dann passiert und die konkrete Implementierung darf selber entscheiden. Oft wird dabei nach Geschwindigkeit entschieden und UB ist in vielen Fällen zu meiden, weil es sein kann, dass alles funktioniert, aber in 10 Jahren und auf einem anderen Betriebssystem irgendwo ein kleiner Fehler auftritt, der alles zum Zusammenbrechen bringt.