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?

try catch haben einen negativn einfluss vor allem wenn wirklich eine Expection geworfen wird. Aus Gründen der Proformanc solte man also versuchen das möglichst selten Expections geworfen werden(vor allem in Schleifen)

gruß Stefan

p.s Benutze auch mal die Forensuche da gibt es noch jede mange anderer Threads die sich mit dem Thema Beschäftigen

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 frage zum Beispiel im Zweifelsfall die zu verwendene Variable auf NULL ab und reagiere vorher, als blind ins offene Messer zu laufen. Ich verwende Try und Catch so wenig wie möglich.

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.

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

Wobei ich als äußersten Block immer einen ganz allgemeinen Exceptionhandler verwenden würde, damit man im Zweifelsfall ein Log schreiben und sauber beenden kann. Das ist immer noch besser als ein Absturz.

Gerade in Threads kann das sehr wichtig sein, da sonst der Thread weg ist ...

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.

Hallo!

Ich erlaube mir hier mal eine Anmerkung (keine Ahnung, obs noch jemand liest 😉 ):

Die IDE _hat _doch schon eine Fehlerbehandlung, und zwar eine hervorragende!
Codestop, Meldung, Propertygrid zur Untersuchung auch der InnerException, Aufrufefenster zur Untersuchung der aktuell auffm Stack befindlichen Prozeduren, und's Lokalfenster zeigt alle geladenen Variablen.

• Das alles gibt man auf, indem man's mit einem trycatch deaktiviert.
  Meist nur, um sich dieselbe Meldung in einer Messagebox anzugucken, und dann ohne die ganze vorgenannte Unterstützung.

Ein Fehler ist nunmal prinzipiell etwas unvorhergesehenes. Und das kann ein Programm nicht behandeln, das muß ein Mensch debuggen.

Und je unbehandelter der Fehler auftritt, desto leichter ist es, die Ursache herauszufinden, (trycatch fängt ja auch Fehler, die ganz woander aufgetreten sind).

Andersrum folgt daraus, dassich fleißig Fehler werfe, nämlich sobald ein ungültiger Zustand bemerkt wird. Eben je früher desto besser.

So als Gesichtspunkt.
Mit Error-Logging kenne ich mich nicht aus, und auch beim Multithreading (Golos Hinweis) ist Fehler fangen wohl besser als sie sich in Luft auflösen lassen.

Also mit einem gut durchdachten Gesamtkonzept im Hintergrund kann sich trycatch bestimmt durchaus nützlich machen.
Und dann gibts sichern Haufen Anwendungsfälle, an die ich jetzt nicht gedacht habe.

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.

Ah. Das mit dem graceful für den Kunden kam nicht so raus, das hat natürlich seine Berechtigung.

Aber IDE-Fehlerbehandlung und trycatch paralell nutzen? - ich kenns halt so: trycatch eingebaut - nix mehr mit Codestopp und PiPaPo.

Wie nutzt man das paralell?

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 😉

Na, das hat sich ja doch wieder sehr gelohnt, dassich mich so unqualifiziert aussm fenster gehängt hab.

😁

Gern geschehen 🙂

Hallo zusammen

Hier noch zwei interessante Links zum Thema:

• http://blog.waitz.biz/2007/03/02/EinPaarGedankenZurAusnahmebehandlung.aspx
• http://blog.norberteder.com/index.php?entry=entry071001-093016 (Weitere Links im Beitrag)

Gruss Peter

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:

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

und du siehst keine möglichkeit z.b. mit einer kopfgesteuerten schleife nur soviele durchläufe zu machen, wie notwendig sind?

übrigens ist es in deinem code so, das die schleife nach einem catch nciht wieder aufgerufen wird.

per definition ist eine ausnahme etwas, das im normalfall garnicht auftritt. in deinem fall ist es keine ausnahme, sondern ein logikelement, welches ein teures und unnötiges konstrukt ist. gerade in deinem code könnte ich mir mit nur ganz wenigen zeilen code mehr, vorstellen, das es sauberer, perfomanter und nachvollziehbarer geht.

ich z.b. vermeide solche konstrukte ala:
class1.method1(..).propertiecollection.method(...).propertie.nestedclass.method(...).ToString();

das ist nicht nur schwierig zu lesen. es ist auch ncoh umständlich zu debuggen.
die zeit, die du zum posten verwendet hast, hätte ausgereicht um den code glattzuziehen.

im übrigen würde jedes codereview dich bei solchen zeilen so richtig zerlegen. vor den augen des projektleiters, was dann gegenargumentationen schwierig macht....

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

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 ...)

Es gibt schon einen Chef, aber der interessiert sich nicht dafür. Ich werde das Prog auch nicht fertigschreiben können, das macht ein Kollege dann, der das ganze dafür aber dann lesen können muss.

Aber stimmt schon, es wird nur 1 mal gecatcht, danach gehts hinter der schleife weiter.
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. Diese Operation ist zwar schwer lang, erspart aber Zwischenvariablen. Mir wurde zwar mitgeteilt, dass die XML's, die ich einlesen soll, nur wenige KB haben, aber es geht hier um den Chip von Kredit/Debitkarten, und der wird ja bekanntlich immer größer und kann immer mehr. Deswegen hab ich mich gegen die Variante mit Variablen entschieden, und einfach Item und Subitem des Listviews in einer einzigen zeile hinzugefügt. Ich werd aber noch n Kommentar dranmachen.

mfg, Rasta (cu, feierabend)

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.

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.

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.

Hallo Rasta,

mich mutet dein Stil schon etwas - sagen wir - exotisch an. Ich verstehe ehrlich gesagt nicht, was du daran findest. quick'n'dirty bedeutet doch, dass man etwas schmutzig macht um schneller zu sein (also weniger Programmieraufwand zu haben). Das ist doch in deinem Beispiel gar nicht der Fall. Es ist schmutzig und weniger schnell. Insgesamt kann ich deiner Vorgehensweise nicht empfehlenswertes abgewinnen.

herbivore

Wie heißt es so schön:

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

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
>

Und? Mal weitergelesen? Der Microbenchmark ist absoluter Quatsch.

Was ich sagen möchte, deine Aussage mit "bedenkenlos benutzten" ist gefährlich. Siehe den Flow-Control-Horror von Rasta. 🙁
Wenn man kann vermeidet man die Exception. Lieber ein TryParse als ein Parse mit Try! Defensive Asserts (if x != null) und Debug.Assert können da helfen.

Almost Rule #1

When deciding if you should throw an exception, pretend that the throw statement makes the computer beep 3 times, and sleep for 2 seconds.

Agreed. Genau so kann man das beschreiben.

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.

Hi,

ich verwende try/catch meist als äußeren Rahmen in meinem Methoden, um dem Benutzer, im Fall der Fälle, ordentliche und angepasste Fehlermeldungen geben zu können. Ansonsten versuche ich immer Exceptions durch sinnvolle Prüfungen alla if(... != null) abzufangen. Das ist Performant und Übersichtlich.

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.

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

Kann man das eleganter lösen?

Kann man das eleganter lösen?

laut anforderung ist das die korrekte lösung.
eine andere möglichkeit wäre, immer die rechte zu prüfen um die exception zu vermeiden aber ich behaute jetzt mal das das abprüfen unperfomanter ist als das try-catch konstrukt.

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.

Nein ist es zum Glück auch nicht. Ich danke für eure Antworten. War mir nicht sicher ob ich was übersehe.

Ü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.

Zugreifbar ist unter Windows so eine Sache. Es gibt so um die 20 Zugriffsrechte:

MSDN: FileSystemRights Enumeration

Vielleicht hilft das als Einstieg ins Thema:

using System;
using System.Collections.Generic;
using System.Linq;
using System.Text;
using System.IO;
using System.Security.AccessControl;
using System.Security.Principal;


namespace ConsoleApplication3
{
    class Program
    {
        static void Main(string[] args)
        {
            string fileObject = @"\Windows\Microsoft.NET\Framework\";
            FileSecurity sec = File.GetAccessControl(fileObject);
            AuthorizationRuleCollection authCol = sec.GetAccessRules(true, true, typeof(NTAccount));

            WindowsIdentity myAccount = System.Security.Principal.WindowsIdentity.GetCurrent();
            Console.WriteLine("Mein Account = " + myAccount.Name.ToString());
            Console.WriteLine(string.Format("\r\nRechte in {0}\r\n", fileObject));
            foreach (IdentityReference group in myAccount.Groups)
            {
                foreach (FileSystemAccessRule rule in authCol)
                {
                    if (group.Translate(typeof(NTAccount)) == rule.IdentityReference)
                    Console.WriteLine(string.Format("Recht {0} über User/Gruppe {1}", rule.FileSystemRights, rule.IdentityReference.Value));
                }
            }
            Console.ReadLine();
        }
    }
}

Aber: Du bekommst auch in diesem Fall eine SecurityException, wenn du keine Lese-Rechte auf dem Objekt hast. Grundsätrzlich kannst du auf Exceptionbehandlung sowieso nicht verzichten. Du kannst bestenfalls einen Großteil der Exceptions vermeiden.

Kann man das eleganter lösen?

Arbeite die Liste asynchron ab.

Ich bin da voll und ganz Golos Meinung

Wenn man Exceptions richtig verwendet gibt es keine Probleme.

Wichtig ist aber auch dass man Exceptions gezielt abfängt

wenn man z.Bsp. weiß, dass eine UnauthorizedAccessException geworfen werden könnte dann sollte man auch konkret diese abfangen und nicht generell Exception.

Ansonsten bekommt man andere Fehler vielleicht garn icht mehr mit?
Man sucht stundenlang nach fehlenden Rechten und dann ist es eine NullRefEx.....

Im allgemeinen verfahre ich so dass eine Methode Möglichst restriktiv Exceptions wirft (jeder Para und zustand wird geprüft). DEr Aufrufer kümmer sich aber darum das alle Paras gültig sind, falls nicht sorgt er schon für ein ausnahme handling bevor der aufruf erfolgt.

So bekommt ein Entwickler direkt feedback wenn eine Komponente falsch / unvorhergesehen verwendet und in der letztendlcihen runtime treten (fast) keine solcher expcetions mehr auf

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

MultiThanx! 🙂

@Haggy: So mache ich das idR. auch. Fast jede Methode bei der ich mir nicht zu Hundert Prozent sicher bin das nur ich sie benutze (also eigentlich jede public Methode) hat einen Block von Parameterprüfungen die alle gezielte Exceptions werfen. Eine Suche nach "throw new" bringt in meinem Programmen meist viele hundert Ergebnisse. 😉

Anders ist es in einer Projektarbeit auch garnicht möglich da ich anderen Entwicklern nicht zumuten kann meinen Code zu verstehen wenn mal ein Parameter falsch sitzt.
Und wenn ich da mit Rückgabecodes (ausser null) arbeiten würde hätte ich wohl bald den Unmut sämtlicher Kollegen auf mich gezogen. Magic Numbers sind hier nicht sonderlich beliebt - und das imho zu Recht.

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.

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.

ich sehe das genau so wie ErfinderDesRades und praktiziere es auch so.

@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.

Hallo zusammen

ich sehe das genau so wie ErfinderDesRades und praktiziere es auch so.

Ich ebenso.

Gruss Peter

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.
>
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.

Hallo zusammen,

ich sehe das genau so wie ErfinderDesRades und praktiziere es auch so.

Dito.

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.

NEIN!!!
Du kannst einfach unter "Debugging - Exceptions" festlegen, bei welchen Exceptions auch unterbrochen werden soll, wenn diese geworfen werden.
Das "Hangeln" durch den Callstack ist auf diese Weise eigentlich nur selten notwendig.

das hangeln durch den callstack muss man eigendlich immer dann machen, wenn man irgendwo ein try-catch hat. sonst lande ich zumindest immer an genau der selben zeile, wo die exception auch wirklich aufgetreten ist.

@winSharp93: Zum einen kann ich an der gleichen Stelle auch festlegen, daß die IDE auch dann anhält wenn ich einen Try...catch Block drum habe und zum anderen stimmt es eben nicht, daß jede Exception zwingend auch an der Stelle gemeldet wird wo sie fliegt - bestes Beispiel, daß ich im Moment habe ist eine OutOfMemory Exception (wir arbeiten mit sehr großen Bilddaten).

Diese fliegt eben nicht an der Stelle wo ich das Objekt anlege sondern irgendwann später - im schlimmsten Fall um Haupthread und dann kann ich mit dem CallStack nix mehr anfangen da der leer ist (bzw. externer Code dazwischen liegt). Fange ich sie aber vorher ab - wie ich es im Moment eben tue - so kann ich sofort sagen welches Objekt diese Exception auslöst und sogar direkt darauf reagieren. Vor allem weiss ich dann genau, daß genau diese eine Methode eine OutOfMemory Exception produzieren kann und bin meinen allgemeinen Exceptionhandler sofort wieder los.

Des weiteren kann ich anhand des TraceLogs später sehen, welche Exception wirklich wichtig war und welche nicht - so kommt es durchaus mal vor das Exceptions fliegen (aus dem Framework heraus) welche keine Auswirkungen auf meinen Code haben. Wenn ich das anhand des TraceLogs sehe hebe ich mir die Optimierung für einen späteren Moment auf (ja, ich Dokumentiere recht genau 😉). Denn nichts ist frustrierender als eine umfangreiche Berechnung zu schreiben und zu testen wenn ständig die IDE anhält und sich beschwert obwohl das auf die Ausführung der Berechnung keinen Einfluss hat.

Wie bereits gesagt, jeder hat seinen Stil und ich fahre mit meinem Recht gut - der Threadtitel lautet ja auch nicht "Missioniert so lange bis ihr alle von eurer Vorgehensweise überzeugt habt" sondern es wurde nach dem Stil gefragt. Und ich habe meinen geschildert und begründet.

PS: Unter C++ habe ich Exceptions gehasst wie die Pest und immer vermieden - unter einer Verwalteten Umgebung wie .net sehe ich keinen sinnvollen Grund mehr das immer noch zu tun.

welche Exception wirklich wichtig war und welche nicht - so kommt es durchaus mal vor das Exceptions fliegen (aus dem Framework heraus) welche keine Auswirkungen auf meinen Code haben

Exceptions stellen Ausnahmen da, die nicht den Normalfall darstellen sollten.
Nach dem Muster "Einfach alle ignorieren, solange die Anwendung läuft", ist meiner Meinung nach ein vollkommen falscher Weg.
Wenn eine Exception geworfen wird, hat das eigentlich immer einen Grund. In so einem Fall ohne triftigen Grund einfach weiter zu machen und zu hoffen, dass schon nichts Tragisches passiert ist / passieren wird, halte ich ehrlich gesagt für naiv.

wenn ständig die IDE anhält und sich beschwert obwohl das auf die Ausführung der Berechnung keinen Einfluss hat.

Gib mir da mal bitte ein Beispiel.
Wenn es keinen Unterschied macht, ob z.B. ein Methodenaufruf erfolgreich war oder nicht, kann man ihn doch auch gleich weglassen?!?

Vor allem weiss ich dann genau, daß genau diese eine Methode eine OutOfMemory Exception produzieren kann und bin meinen allgemeinen Exceptionhandler sofort wieder los.

Gerade eine OutOfMemoryException kann prinzipiell überall auftreten.
Daher halte ich es für nicht sinnvoll, alle Methoden, die irgendwann während der Testphase eine werfen, als gesondert zu behandeln.
Es stört ja nicht, wenn die Exception erst ein paar Ebenen höher abgefangen wird.

Hallo LuckyGeorge

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.

Meinst du jetzt deine Methoden, oder welche Exceptions deine Methode aufgrund von .NET Framework Code werfen könnte?

Gruss Peter

Die Klasse MemoryFailPoint kann helfen, OutOfMemoryExceptions an "zufälligen Stellen" zu vermeiden

Kante ich noch nicht - danke, werde ich mir anschauen.

Exceptions stellen Ausnahmen da, die nicht den Normalfall darstellen sollten.
Nach dem Muster "Einfach alle ignorieren, solange die Anwendung läuft", ist meiner Meinung nach ein vollkommen falscher Weg.
Wenn eine Exception geworfen wird, hat das eigentlich immer einen Grund. In so einem Fall ohne triftigen Grund einfach weiter zu machen und zu hoffen, dass schon nichts Tragisches passiert ist / passieren wird, halte ich ehrlich gesagt für naiv.

Danke für das Kompliment aber Du hast mich missverstanden (hoffe ich zumindest). Die fertige Applikation oder DLL ist aufgeräumt, daß heisst das (fast) alle unnötigen try...catch Blöcke draussen sind und eben keine wichtige Exception ignoriert wird. Ich hoffe also nicht darauf, daß schon nichts schlimmes passieren wird. Ich strukturiere nur meine Arbeit so, daß ich mich mal um die GUI kümmere, mal um die Hardware, mal um die Datenbank und mal um die Berechnungen - und dann ist nichts lästiger als Fehler in Programmteilen zu beheben die man im Moment garnicht zum Test benötigt. Mich lenkt das zumindest ab.

Gib mir da mal bitte ein Beispiel.
Wenn es keinen Unterschied macht, ob z.B. ein Methodenaufruf erfolgreich war oder nicht, kann man ihn doch auch gleich weglassen?!?

Gern. Habe gerade einen recht aufwendigen Algorithmus zur Medianfilterung geschrieben. Die Parameter werden in der GUI eingegeben welche ich schon letzte Woche erstellt habe. Würde ich in der GUI nicht erstmal sämtliche Eingabefehler abfangen (und da gab es ein paar FormatExceptions) hätte ich heute den Tag damit verbracht die GUI Fehler zu beheben und müsste mich danach wieder in den Algorithmus reindenken. So habe ich den Algorithmus getestet, er funktioniert und morgen behebe ich die FormatExceptions. Ich - im Gegensatz zu meinem PC - bin nicht MultiTaskingfähig.

Gerade eine OutOfMemoryException kann prinzipiell überall auftreten.
Daher halte ich es für nicht sinnvoll, alle Methoden, die irgendwann während der Testphase eine werfen, als gesondert zu behandeln.
Es stört ja nicht, wenn die Exception erst ein paar Ebenen höher abgefangen wird.

Sicher kann ich nicht jeden Punkt einer OutOfMemory Exception sauber abfangen und darauf reagieren und Du hast Recht - das kann überall passieren.
Wenn aber - und auch das ist ein aktuelles Beispiel, die OutOfMemoryException einfach nur bei der Übergabe eines Bildes an ein WPF Image (innerhalb eines ElementHost) auftritt und ich dieses Bild eigentlich nur Anzeige weil ich allein was sehen will, die Applikation danach jedoch einen Algorithmus startet und genug Zeit zur GarbageCollection hat und mich danach nur das Ergebniss interessiert (das Bild war ja nur nice to have). So fange ich die einfach genau an der Stelle ab - wen störts denn? Niemanden.
Aber ich habe ein schönes TraceLog und weiss ganz genau das ich mich um dieses Problem noch kümmern muss - ohne jedoch meine aktuellen Überlegungen bezüglich des Programmablaufes zu unterbrechen.

Die try...catch Blöcke helfen mir also meine Arbeit zu strukturiueren und mich nicht in Details zu verlieren - allerdings setzen sie eben vorraus, daß ich nach jedem MileStone meine bisherige Arbeit bereinige. Netter Nebeneffekt dieser Bereinigung ist allerdings auch, daß man jede Methode nochmal anfasst, redundante Methoden rauswirft und bestimmte Sachen eleganter löst als man es sich zum Zeitpunkt der Erstimplementierung vorstellen konnte. Ich bin kein Freund von "Was einmal läuft, läuft" - es geht immer besser. Und auch wenn dies nicht der Hauptgrund für meine CatchAll Einstellung ist so ist dies doch ein Teil davon.

Hallo Peter,

ich meine letzteres - also welche Exceptions aus dem Framework fliegen können. Was mein Code anstellt sollte ich schon wissen - hoffentlich. 😉

Die Methoden und Properties des Frameworks sind eigentlich sehr detailliert dokumentiert, unter anderem auch welche Exceptions auftreten können.
Von daher weißt du auch, was auftreten kann.

@JunkyXL:

Sicher sind sie das - naja, es sei denn man muss, so wie ich im Moment - WPF mit den netFX Extensions implementieren und hat nur einen sehr eingeschränkten Internetzugang. Dann hat man ein kleines Problem. Und wenn ich recht überlege hatte ich dieses - oder ähnliche Probleme das ganze letzte Jahr über. Ein Internetanschluss am EntwicklerPC war eigentlich nie vorhanden und mitunter noch nichtmal die MSDN.
Zudem stört es die Entwicklung ein wenig, wenn man vor jedem Aufruf erstmal prüft, was für mögliche Exceptions auftreten können, diese dann vermeidet nur um festzustellen, daß die Grundüberlegung für die Methode falsch ist und man sich die Arbeit umsonst gemacht hat. Hätte man es einfach runterprogrammiert wäre wahrscheinlich keine der Exception geflogen und man hätte sich zumindest diese Arbeit gespart.
Ich bin nicht in der Lage aus dem Stand immer perfekt funktionierende Methoden zu schreiben - aber bitte verrate das nicht meinen Kunden. Die sind bis jetzt mit mir zufrieden. 😉

aber Du hast mich missverstanden (hoffe ich zumindest).

Ja, zumindest teilweise.

Was aber dennoch der Fall zu sein scheint: Wenn eine Exception während des Debuggens bei dir nicht auftritt, weil z.B. eine Datei vorhanden ist, dann wird diese nie berücksichtigt, oder?

Die Parameter werden in der GUI eingegeben welche ich schon letzte Woche erstellt habe. Würde ich in der GUI nicht erstmal sämtliche Eingabefehler abfangen (und da gab es ein paar FormatExceptions) hätte ich heute den Tag damit verbracht die GUI Fehler zu beheben und müsste mich danach wieder in den Algorithmus reindenken. So habe ich den Algorithmus getestet, er funktioniert und morgen behebe ich die FormatExceptions.

Aus diesem Grund wurde das Unittesting "erfunden": Komponenten werden möglichst unabhängig getestet.

Sicher sind sie das (gut dokumentiert) - naja, es sei denn man muss, so wie ich im Moment - WPF mit den netFX Extensions implementieren und hat nur einen sehr eingeschränkten Internetzugang. Dann hat man ein kleines Problem.

Hmm.
Ich brauche nie INet, um FX-Doku zu lesen. Offline ist die MSDN ist viel besser (überhaupt!) sortiert.
gugge Möglichkeiten der Informationsgewinnung
Kann natürlich sein, daß du iwas supermodernes proggst, für das Offline-MSDN veraltet ist.