try/catch: Programmierstil

Ich arbeite bei meinem Programmen relativ häufig mit try und catch.

Ist das eurer Meinung nach ein schlechter Programmierstil, weil man lieber den Code so ausfeilen sollte, dass gar keine Exceptions mehr möglich sind und man somit auf try und catch verzichten kann?
Oder sollte man doch lieber ein try und catch mehr setzen, als eins zu wenig zu haben und damit einen kompletten Programmabsturz bei Exceptions zu riskieren, mit denen man nicht gerechnet hat?

Haben try und catch einen negativen Einfluss auf die Performance?

Sorry, aber das ist vollständiger Quatsch, dass Exceptions langsam wären ... das ist so eine der unausrottbaren Urban Legends in der IT.

Exceptions haben keinen negativen Einfluss auf die Performance, und können von daher bedenkenlos genutzt werden. Für eine Erklärung, woher diese Urban Legend kommt, siehe  http://www.yoda.arachsys.com/csharp/exceptions.html

Abgesehen davon sollte eine Exception (wie der Name ja schon sagt) nur eine Ausnahme darstellen, und wenn die Software eh in einen Fehler läuft, wen juckt dann noch großartig die Performance? Die Fehlerbehandlung ist mit Sicherheit performancelastiger als das bissle, was try / catch verbraucht ;-).

Ich verwende try/catch ziemlich selten, und wenn doch, dann nur weil ich nicht weiß, wie ich den Fehler umgehen kann. Dann verwende ich aber gezielte catch wie z. B.

C#-Code:

catch(System.UnauthorizedAccessException ex) {    //Gib eine Meldung aus. }

In .NET ist man gezwungen an vielen Stellen Exceptions zu behandeln. Insofern stellt sich die Frage nach der Benutzung nicht. Die Frage ist höchstens, ob man innerhalb der Anwendung eigene Exceptions definiert und wirft.

Exception sind ja nicht umsonst eingeführt worden. Sie erlauben eine Fehlerbehandlung, die tendenziell mächtiger und auch weniger geschwätzig ist. Die Kosten einer Exceptionbehandlung (nach Auftreten!) sind allerdings nicht gering, so dass man Exception - wie Golo schon schrieb - eben nur für Ausnahmen verwenden sollte (meist dann, wenn der Code selbst eine Exception warf...).

Es gibt diverse Artikel im Netz, die sich mit Fehlerbehandlungsstrategien beschäftigen. Am besten mal einlesen.

Zitat von ErfinderDesRades:

Hallo! Die IDE hat doch schon eine Fehlerbehandlung, und zwar eine hervorragende!

Es geht doch vor allem aber auch darum, einen Fehler "graceful" behandeln zu können, wenn er beim Kunden auftritt, wo eben keine IDE da ist ... und ein try/catch stört die Fehlerbehandlung in der IDE auch nicht, lässt sich ja beides parallel nutzen.

In VS 2005 z.B.:

Menü Debug > Exceptions > Break when an exception is thrown => Häkchen rein, und Du bekommst den Debugger nicht nur bei unbehandelten Exceptions, sondern bei jeder Exception ... kannst sogar einzelne Exceptiontypen einzeln aussuchen ;-)

Gern geschehen :-)

Ich nehme auch ziemlich oft try catch, oft auch, wenn ich ganz bewusst weiss, dass es ne Exception geben wird (ich gebe zu, das ist schlechter programmierstil, aber was solls).

Beispiel:

C#-Code:

try             {                 do                 {                     ListView_InfoBox.Items.Add(EF_ID_Feldnamen_nodelist.Item (i).Attributes.Item (0).InnerText).SubItems.Add (EF_ID_Daten[i]);                     i++;                 } while (i != 45); //Die Schleife wird öfter durchlaufen als nötig, die leeren Einträge werden weg-gecatcht (quick n' dirty^2)             }             catch (Exception)             { }

wie schon im kommentar steht: quick n dirty.
Durchschnittlich gibt es nur 30 Elemente (i=30), aber es werden immer 45 durchläufe gemacht. Das heisst, das Programm führt aus, was es soll, und läuft dann erstmal 15 mal gegen die wand, bevor es das macht, was es machen soll xD

mfg, Rasta

Jo, findich eigentlich gut: Wenn man weiß was man macht, und dazuschreibt, dann kann man eigentlich so dreckig proggen, wie man will
Aber dein Beispiel scheint mir nicht gut gewählt:
Ich denke, die Schleife wird beim ersten Auftritt einer Exception verlassen, nicht wie das was du denkst. Und ein einfaches

C#-Code:

for(i=0; i<EF_ID_Feldnamen_nodelist.Count; i++){}

scheint mir nicht nur quickiger, sondern auch noch weniger dirty, odr?

[OT: Jack war schneller](... einen Chef darfs natürlich auch net geben ...)

Zitat:

Wenn man das allerdings annimmt, ist das wegcatchen deutlich perfomanter als mehrere If's, die nur prüfen, ob die darauffolgende Bandwurmoperation möglich ist, denke ich.

wenn man das annimt, dann stimmt das. jedoch ist es nicht so. nur weil das für dich weniger zeilen sind, heißt das nciht, das du keine komplexen mechanismen damit in gang setzt.

Zitat:

das macht ein Kollege dann, der das ganze dafür aber dann lesen können muss.

er wird sich in gedanken oft an dich erinnern.

Zitat:

Deswegen hab ich mich gegen die Variante mit Variablen entschieden

informationstechnisch ist die zeit der speicherkritischen pc-programmierung vergleichbar mit steinzeit und heute. die paar bytes, die du dadurch einsparst, gehen in einem wartbarkeits, dokumentations und debugging overhead unter.

Wie heißt es so schön:

"The problem with quick and dirty is that dirty remains while quick is long gone."

Du kannst Exceptions bedenkenlos einsetzen, wenn Du sie als das einsetzt, was sie dem Namen nach sind: Ausnahmen.

Exceptions sollten NICHT zur Implementierung normaler Anwendungslogik genutzt werden.

Hallo.

Auch wenn dieser Thread schon etwas älter ist, denke ich das meine Frage gut hier hinein passt. Ich habe mich mit google und hier Forum schon umgeschaut und nichts wirklich gefunden.

Ich habe ein try-catch Konstrukt in einer while-Schleife, da ich nach der exception weiterlaufen muss. Mir gefällt das aber nicht wirklich, da es unperformant ist und die while-Schleife schonmal 200.000(oder mehr) Durchläufe haben kann.

C#-Code:

while (pEnumerator.MoveNext()) {     try     {         // do something     }     catch (UnauthorizedAccessException e)     {          // do something     } }

Kann man das eleganter lösen?

Zitat von sonnendeck2000:

Mir gefällt das aber nicht wirklich, da es unperformant ist

Aber nur, wenn tatsächlich Exceptions auftreten.
Und das sollte nicht der Regelfall sein.

Über die UnauthorizedAccessException binnich auch schon schier verzweifelt.
Ich hab nicht rausgefunden, wie man die Rechte abprüft, und unter Vista, oder überhaupt, wenn man nicht als Admin im Dateisystem unterwegs ist, ist diese Ausnahme durchaus ein Normalfall.
Mir scheints da am Design z.B. der DirectoryInfo-Klasse zu fehlen, daß die nicht angeben kann, ob Zugriff möglich oder nicht.
Oder gleich ein GetDirectories(), welches nicht-zugreifbare gleich ausspart.

Zitat:

Kann man das eleganter lösen?

Arbeite die Liste asynchron ab.

@svenson:
Jo, das ist genau der part, den ich nie gebacken gekriegt habe.

MultiThanx!

Zitat von LuckyGeorge:

Ebenso behandle ich zur Entwicklungszeit das Abfangen der Excpetions - grundsätzlich kriegt fast jede Methode erstmal einen allgemeinen try..catch verpasst. Nachdem die Applikation das tut was sie soll gehe ich via FxCop und StyleCop durch die Assembly und schmeisse alle Blöcke wieder raus bzw. ersetze sie wo nötig durch gezieltes ExceptionHandling.

Versteh ich nicht - Ich empfehle immer die genau gegenteilige Vorgehensweise.  AvoidTryCatch
Also zur Entwicklungszeit, und bis die Applikation ungefähr das tut was sie soll, genau keine TryCatchens, weil die Fehlerbehandlung der IDE zum Entwickeln die bestmögliche überhaupt ist.
Erst ganz am Schluß, wenn man überhaupt ein Konzept haben kann, wies nach einem Fehler weitergehen soll, und wenn die Möglichkeiten ausgeschöpft sind, TryCatch durch Abprüfen des Kontextes zu vermeiden, dann spendier ich mal einen.

@LuckyGeorge:
In de SW Entwicklung ist nichts so beständig wie das Provisorium, deshalb
wird dein ansatz dazu führen, das du die Exceptions manchmal nicht entfernst,
und dann hast Du das Problem.

Also lieber gleich die richtigen einbauen.

Zitat von ErfinderDesRades:

Zitat von LuckyGeorge: Ebenso behandle ich zur Entwicklungszeit das Abfangen der Excpetions - grundsätzlich kriegt fast jede Methode erstmal einen allgemeinen try..catch verpasst. Nachdem die Applikation das tut was sie soll gehe ich via FxCop und StyleCop durch die Assembly und schmeisse alle Blöcke wieder raus bzw. ersetze sie wo nötig durch gezieltes ExceptionHandling. Versteh ich nicht - Ich empfehle immer die genau gegenteilige Vorgehensweise.  AvoidTryCatch Also zur Entwicklungszeit, und bis die Applikation ungefähr das tut was sie soll, genau keine TryCatchens, weil die Fehlerbehandlung der IDE zum Entwickeln die bestmögliche überhaupt ist. Erst ganz am Schluß, wenn man überhaupt ein Konzept haben kann, wies nach einem Fehler weitergehen soll, und wenn die Möglichkeiten ausgeschöpft sind, TryCatch durch Abprüfen des Kontextes zu vermeiden, dann spendier ich mal einen.

Hmm, leider habe ich trotz mehrjähriger Tätigekit noch nicht die Erfahrung zu wissen, welche Exceptions meine Methoden werfen können bevor die Methode fertig ist. Deshalb bin ich bisher mit meinem Ansatz recht gut gefahren.
Und so gut ist die Fehlerbehandlung der IDE auch nicht - wenn ich den try Catch Block weglasse fliegen mir manche Exceptions erst im Haupthread - dann muss ich aufwendig durch die Aufrufliste gehen um festzustellen wo eigentlich der Unsinn passiert ist. Ein simples try...catch um die Methode und dann eine Consolen bzw. Tracer Ausgabe und schon was ich was, wann und wo passierte. Aber gut - jeder hat halt seinen Stil.

@FZelle: Es mag sein, daß es an meiner Tätigkeit als Freelancer liegt - aber bisher waren in jedem Projekt mindestens die letzten 2 Wochen eines Projektes für Dokumentation und Aufräumen vorgesehen. Und die lasse ich mir nicht nehmen egal, wie sich der Kunde anstellt. Die Konsequenz wäre sonst das ich vor lauter Anrufen von Altkunden nicht mehr zum arbeiten komme.
Abgesehen davon habe ich auch während der Projektlaufzeit immer wieder mal einen Hänger bei dem ich nicht weiss wie ich nun den nächsten Schritt am besten anfange - das ist dann perfekte Zeit für den FXCop.

Es mag sein (und ist auch wahrscheinlich), daß auch mal ein try...catch Block übersehen wird. Dieser tut dann idR. aber keinem weh, da er sich nur an einer unkritischen Stelle befinden kann. Sämtliche Zeitfressenden Routinen werden bereits zur Entwicklungszeit weitesgehend optimiert. Also sehe ich da kein Problem.

Es ist halt meine Erfahrung - und die ist ja definitionsgemäß bei jedem anders - das ungewöhnliche Programmabstürze, GUI Hänger oder ein nicht gewolltes Laufverhalten fast immer darauf zurückzuführen sind das eine Exception nicht oder nur unzureichend abgefangen wurde.

Und auch wenn ich hier eine Mehrheit sehe, die das anders handhabt - ich denke mir halt, daß das Framework nicht nur deswegen bei jedem noch so kleinen Fehler eine Exception wirft damit wir im VS eine schöne volle Console haben sondern damit wir darauf reagieren können. Der Performanceverlust innerhalb des Frameworks durch das Werfen der Exception ist doch eh schon da - da macht das Abfangen derselben den Kohl nicht mehr fett.