Exception oder Rückgabewert?
-
Ich würde immer noch SmartPointer verwenden.
Liest den keiner meine Postings (
)mfg JJ
-
Shade Of Mine schrieb:
@SirLant
Was machst du denn, wenn der Zeiger 0 ist? Wie verhält sich dein Programm dann? Einfach return; damit man den Fehler schön leicht ignorieren kann?Kommt drauf an je nachdem wo es passiert geb ich ne MessageBox aus oder schmeiß ne Exception.
Assert könnte ich natürlich auch verwenden aber wenn ich nen debug-build habe brauche ich das nicht da ich da sowieso die Zeile angezeigt bekomme und die Zeiger die immer NULL sein können weil man Ressourcen anfordert die prüfe ich immer mit nem if und handle entsprechend je nachdem muss das Programm ja gar nicht beenden.
-
Sorry das ich mich erst jetzt melde, aber ich hab keine Benachrichtigung mehr bekommen

Ich geh mal auf einige Punkte ein:
- Exceptions sind schneller als If-Abfragen auf den Return Code
Ganz im Gegenteil, bei Return-Werten machst du immer einer if-Abfrage, selbst wenn kein Fehler auftritt. Bei Exceptions kommst du in den catch-Block, nur wenn ein Fehler auftritt.
Und wie kommt das Programm dann in den Catch-Block? Nur weil du kein If machst, heisst das noch lange nicht, dass der Compiler da keins macht.
-
Asserts
Normalerweise werden Asserts nur in Debug-Versionen hineinkompiliert. In Release Versionen werden die meistens automatisch abgeschaltet. Man muss ein Assert wie eine Sollbruchstelle sehen. "Ich vermute, da könnte ein Fehler auftreten aber wirklich abfangen kann ich nicht, oder bin zu faul für". Zumindestens denk ich so, wenn ein fremdes Programm mit einem Assert aussteigt.
zum Beispiel wenn eine externe Datei, ein Registry-Schlüssel oder ein Server nicht erreichbar ist. Dann kann ich eine auch für den User sinnvolle Fehlermeldung ausgeben und das Programm auf jeden Fall beenden (wenn übergreifende try-Behandlung gibt)
Das Kann ich mit einem Return Code auch. (oder mit errno
) Wobei eine Exception schon was heftiger ist, Catch or die() könnte man hier fast schon sagen, einen ungültigen Return Code kann ich in vielen Fällen ignoren, die Exception muß ich abfangen.aber gehen wir mal zum spass von ner speicherintensiven anwendung aus bei der keine exceptions benutzt werden dürfen
C/C++ Code:
char* p1=NULL,p2=NULL,p3=NULL; //mach was p1 = new char[/*variabel*/]; if ( p1 == NULL ) //return //mach was p2 = new char[/*variabel*/]; if ( p1 == NULL ) //return //mach was p3 = new char[/*variabel*/]; if ( p1 == NULL ) //returnwie würdest du hier am besten sicherstellen, dass aufgeräumt wird und gleichzeitig redundanten code vermeiden?
If-Blöcke schachteln, zieht zwar bescheuert aus, wäre aber eine möglichkeit
if (p1 = new char[...]) { if (p2 = new char[...]) { if (p3 = new char[...]) { //perfekt .. // mach perfide dinge } delete p2; } delete p1; } return -1;Wie ist das eigentlich, wird man eigentlich zu Try/Catch Blöcken gezwungen, wenn man eine Funktion mit throws() deklariert, also wie in Java?
-
nein. wird etwas geworfen, und du hats garkein catch drin, so geht dir das programm einfach nur den bach runter.
-
Evil Azrael schrieb:
Und wie kommt das Programm dann in den Catch-Block? Nur weil du kein If machst, heisst das noch lange nicht, dass der Compiler da keins macht.
Stack unwinding. Ist zwar nicht gratis - aber du hast trotzdem nicht soviele Sprünge drinnen (und es kann theoretisch gratis sein - praktisch gesehen gibt es aber keine implementierung die das kann).
Normalerweise werden Asserts nur in Debug-Versionen hineinkompiliert. In Release Versionen werden die meistens automatisch abgeschaltet. Man muss ein Assert wie eine Sollbruchstelle sehen. "Ich vermute, da könnte ein Fehler auftreten aber wirklich abfangen kann ich nicht, oder bin zu faul für". Zumindestens denk ich so, wenn ein fremdes Programm mit einem Assert aussteigt.
Ein assert ist nur zu Debug Zwecken da. Es fängt logikfehler des Programmierers ab. In der Release Version ist nicht mehr vorhanden (denn dann sollte es keine logikfehler mehr geben)
Das Kann ich mit einem Return Code auch. (oder mit errno
) Wobei eine Exception schon was heftiger ist, Catch or die() könnte man hier fast schon sagen, einen ungültigen Return Code kann ich in vielen Fällen ignoren, die Exception muß ich abfangen.Pluspunkt für Exception.
Oder willst du einen Fehler ignorieren?try/catch und die() sind vollkommen unterschiedlich.
If-Blöcke schachteln, zieht zwar bescheuert aus, wäre aber eine möglichkeit
Bloß nicht. Wir haben seit Jahren das RAII-Idiom - wer sowas macht, sollte lieber nach Java/C# wechseln, da hat man finally für soetwas
Wie ist das eigentlich, wird man eigentlich zu Try/Catch Blöcken gezwungen, wenn man eine Funktion mit throws() deklariert, also wie in Java?
Man verwendet keine Exception Spezifikationen in C++
und checked exceptions gibt es nur in Java (ein mechanismus der sehr zweifelhaft ist)Exception in C++ haben generell erstmal nur sehr wenig mit try/catch zu tun.
Tatsächlich habe ich keine 10 "try"s in meinen codes (ich rede von kompletten anwendungen).
C++ macht es hier wesentlich anders als Java/C# - das kann man nicht vergleichen.
-
Shade Of Mine schrieb:
Evil Azrael schrieb:
Und wie kommt das Programm dann in den Catch-Block? Nur weil du kein If machst, heisst das noch lange nicht, dass der Compiler da keins macht.
Stack unwinding. Ist zwar nicht gratis - aber du hast trotzdem nicht soviele Sprünge drinnen (und es kann theoretisch gratis sein - praktisch gesehen gibt es aber keine implementierung die das kann).
Na schön, aber selbst dann muss er irgendwo gucken, ob er´s behandeln muss oder nicht, oder?
Hast du eine Idee, wie man das "gratis" realisieren könnte?Normalerweise werden Asserts nur in Debug-Versionen hineinkompiliert. In Release Versionen werden die meistens automatisch abgeschaltet. Man muss ein Assert wie eine Sollbruchstelle sehen. "Ich vermute, da könnte ein Fehler auftreten aber wirklich abfangen kann ich nicht, oder bin zu faul für". Zumindestens denk ich so, wenn ein fremdes Programm mit einem Assert aussteigt.
Ein assert ist nur zu Debug Zwecken da. Es fängt logikfehler des Programmierers ab. In der Release Version ist nicht mehr vorhanden (denn dann sollte es keine logikfehler mehr geben)
Brauchst du mir nicht zu erklären, ich kenne die assert anweisung (oder makro).
Das Kann ich mit einem Return Code auch. (oder mit errno
) Wobei eine Exception schon was heftiger ist, Catch or die() könnte man hier fast schon sagen, einen ungültigen Return Code kann ich in vielen Fällen ignoren, die Exception muß ich abfangen.Pluspunkt für Exception.
Oder willst du einen Fehler ignorieren?Machmal gibt es Fehler und Warnungen, die kann man ignorieren.
try/catch und die() sind vollkommen unterschiedlich.
Was soll mir das jetzt sagen?
If-Blöcke schachteln, zieht zwar bescheuert aus, wäre aber eine möglichkeit
Bloß nicht. Wir haben seit Jahren das RAII-Idiom - wer sowas macht, sollte lieber nach Java/C# wechseln, da hat man finally für soetwas
Was ist das RAII Idiom? Was macht finally?
Was hast du gegen die Schachtelung ausser dass es sehr in die "Breite" geht. Mach doch einen besseren Vorschlag.Wie ist das eigentlich, wird man eigentlich zu Try/Catch Blöcken gezwungen, wenn man eine Funktion mit throws() deklariert, also wie in Java?
Man verwendet keine Exception Spezifikationen in C++
und checked exceptions gibt es nur in Java (ein mechanismus der sehr zweifelhaft ist)Exception in C++ haben generell erstmal nur sehr wenig mit try/catch zu tun.
Tatsächlich habe ich keine 10 "try"s in meinen codes (ich rede von kompletten anwendungen).
C++ macht es hier wesentlich anders als Java/C# - das kann man nicht vergleichen.Wieso haben Exception recht wenig mit try/catch zu tun? Über ein paar Erklärungen würd ich mich sehr freuen. Enlight me, please...
-
Evil Azrael schrieb:
Machmal gibt es Fehler und Warnungen, die kann man ignorieren.
Wenn du einen Fehler ignorieren kannst, dann ist es auch keiner.
Ich weiss aber schon, es gibt API's die solche blöden Sachen machen.
-
Evil Azrael schrieb:
Na schön, aber selbst dann muss er irgendwo gucken, ob er´s behandeln muss oder nicht, oder?
Hast du eine Idee, wie man das "gratis" realisieren könnte?Nein, mir fehlt leider das Verständnis für die verschiedenen Möglichkeiten Exception zu implementieren...
Machmal gibt es Fehler und Warnungen, die kann man ignorieren.
zB?
try/catch und die() sind vollkommen unterschiedlich.
Was soll mir das jetzt sagen?
Dass ein die() sofortigen Abbruch bedeutet und Exception lediglich Fehler melden...
Was ist das RAII Idiom? Was macht finally?
try/catch/finally.
Finally wird immer ausgeführt, egal ob eine Exception geflogen ist.File f; try { f=new File("foo"); f.write(..); } catch(Exception e) { log(e); } finally { f.close(); }f.close() wird immer ausgeführt, egal ob ein Fehler aufgetreten ist, oder nicht.
RAII: http://de.wikipedia.org/wiki/RAII
Was hast du gegen die Schachtelung ausser dass es sehr in die "Breite" geht. Mach doch einen besseren Vorschlag.
Einfach veraltet, fehleranfällig, umständlich und schwer wartbar/lesbar.
Wieso haben Exception recht wenig mit try/catch zu tun? Über ein paar Erklärungen würd ich mich sehr freuen. Enlight me, please...
Puh, dir fehlt scheinbar das verständnis für C++ Exception. So schnell ist das nicht erklärt.
Kurz zusammengefasst (Exceptional C++ erklärt es vermutlich besser):
Exception sind Ausnahmen und treten somit nur selten auf. Es geht dabei weniger um try/catch weil man mit RAII sich ein try/catch und dann weiterwerfen sparen kann. Auch ein finally ist deshalb nicht nötig.Die Idee ist nun: try/catch kommt nur dort vor, wo man auch wirklich eine Ausnahme behandeln kann - und das ist normalerweise nur an einigen wenigen zentralen Punkten.
Viel mehr geht es bei Exception in C++ darum, Exception sicher zu sein - dh, trotz dem auftreten von Exception konsistent zu bleiben.
char* p=new char[100]; char* p2=new char[100];ist zB Fehlerhaft, weil p nicht freigegeben wird, wenn p2 fehlschlägt.
In java würde man es so machen (C++ Code):
char* p=0; char* p2=0; try { p=new char[100]; p2=new char[100]; } finally { delete p; delete p2; }In C++ dagegen so (mal angenommen array_ptr ist ein smartpointer ala auto_ptr nur für arrays):
array_ptr<char> p(new char[100]); array_ptr<char> p2(new char[100]);wir haben jetzt exception sicherern code ohne try/catch geschrieben. und so geht es eben die meiste zeit - bis man auf den Fehler reagieren kann - was, wie gesagt normalerweise an wenigen zentralen stellen der fall ist.
Natürlich ist da jetzt nur ein kurz überblick - wirklich lohnen würde es sich, wenn du dir die GotW durchlesen würdest (http://www.gotw.ca/gotw/) Da sind einige Artikel davon behandeln Exception.
-
Und wenn man nicht Bjarne glauben darf, wem dann? :p Zitat aus seinem Buch "Die C++ Programmiersprache", Kapitel 14.8:
Prinzipiell kann die Ausnahmebehandlung so implemetiert werden, daß kein Mehraufwand zur Laufzeit auftritt, wenn keine Ausnahme geworfen wird. Zusätzlich kann das werfen so realisiert werden, daß es nicht viel aufwendiger als ein normaler Funktionsaufruf ist. [...] Allerdings muß man in Erinnerung behalten, daß die Alternativen zur Ausnahmebehandlung auch nicht umsonst sind. Es ist nicht unüblich, daß sich in traditionellen Systemen die Hälfte des Codes mit Fehlerbehandlung beschäftigt.
-
Shade wozu nen array_ptr dafür hat man doch vector
-
A std::vector is an alternative to a array_ptr that is a bit heavier duty but far more flexible. A boost::array is an alternative that does not use dynamic allocation.
-
SirLant schrieb:
Shade wozu nen array_ptr dafür hat man doch vector
Als Beispiel für Ressourcen. Da ein vector Copyconstructable verlangt, kann ich manche Ressourcen nicht da reinpacken. Aber ich wollte eigentlich nur smart pointer verwenden, und da der original Code Arrays hatte, habe ich halt auch welche verwendet.
Hat also keinen bestimmten Grund. Nur vector hätte wegen der Erklärung nicht gepasst... Höchstens ein vector<shared_ptr<>> wobei ich sowas eigentlich nicht verwende...
-
es gibt in boost auch smart_ptr die nur für arrays gemacht worden sind

-
Interesting post )
http://bnbkjsdpu.com my blog
-
Troll.