try funktion erläutern

Nachtrag:
Was meine ich mit Scheinwelt:
Eine Welt, in der man jeden möglichen Fehler vorhersagen kann, bzw VOR Auftreten des Fehlers durch eine wie auch immer geartete Prüfung genau diesen Fehler vermeiden kann.
Und das KANN nicht gehen, da ein Programm immer einen ZEITLICHEN Ablauf hat und es demzufolge unmöglich ist, in die Zukunft zu schauen. Wenn aber ein Zustand sich in der Zukunft ändern kann, dann ist es absolut unmöglich diese Zustandsänderung vorherzusagen bzw zu vermeiden!

Wenn du meinst "avoid try catch, if you are an idiot", dann solltest du das klar sagen.

ähm - da sagichjetzt bessernix

gleich 5 Schrott-Beispiele

von einer messagebox geht der UsbStick auch nicht wieder rein.

man man facepalm, du meinst also ernsthaft wenn nen fehler auftritt wie z.b. nen konvertierungsfehler oder halt nen rechte konflikt oder nen outofrange fehler oder sontwas, soll man gleich das prog beenden, anstatt den user darauf hinzuweisen bzw zu fragen ob ers erneut versuchen will? wie sähe das unter windows aus wenn ne datei nicht kopiert werden kann weil sie gerade benutzt wird, direkt zum bluescreen crashen oderwas?

Hm, wenn ich mir den Thread so durchlese frage ich mich warum es so schwer ist.
Eigentlich finde ich, dass es ganz simpel ist:

Try-Catch unnötig: (Das ist genau das, was ErfinderDesRades in Post #14 im zweiten Absatz mit dem letzten Wort gemeint hat)

Stattdessen:


Try-Catch sinnvoll:


Und @ErfinderDesRades(Post #22):
Was die Beispiele angeht: Das erste Beispiel ist wirklich nicht gerade praxisnah (siehe drittes Codeschnipsel).
Mit SQL Clients, WebClients und HttpRequests kenne ich mich zu wenig aus um sagen zu können, ob es bereits im Voraus überprüfbar ist.
Aber ein Beispiel ist definitiv sinnvoll (es sei denn es gibt eine (angemessene) Methode es vorher festzustellen. Und das ist das Beispiel mit Bitmap.FromFile() (siehe ebenfalls drittes Codeschnipsel).

Meine persönliche Meinung: Ich bin noch nie auf eine Situation gestoßen, bei der ich Try-Catch wirklich benötigt hätte.
Ich habe es ein mal benötigt: Bei einem 5-Minuten Programmen, das nur da ist um die nächste halbe Stunde die Größe von Bildern zu ändern, und wenn es bei einem schief geht war's auch egal.

Wenn ich - wie z.B. beim dritten Codeschnipsel - am Ende von IntelliSense, am Ende des ObjectBrowsers und am Ende meiner Geduld mit Google bin,
dann löse ich gezielt Exceptions aus und fange den entsprechenden Typ mit Catch ex As ColaInKeyBoardException ab und
reagiere wenn möglich mit einer angemessenen Lösung, bei der keine gefährlichen Zustände auftreten (siehe ErfinderDesRades in Post #9), z.B. KeyBoard.ClearAllCola(),
oder mit einem gezielten Beenden des Programmes, mit allem was dazu gehört (Backup-Dateien mit allen vorhandenen Informationen erstellen, den User informieren, Fehlerinformationen ausgeben, etc.).

Das ist meine subjektive Meinung dazu.

Gelöschter Benutzer schrieb:

konvertierungsfehler oder halt nen rechte konflikt oder nen outofrange fehler

in jedem deiner Beispiele hat der Programmierer höchstwahrscheinlich eklatanten Mist verzapft.

Er sollte unbedingt die angesprochenen Exceptions während der Entwicklung nutzen, um seine Fehler zu beheben statt zur Laufzeit was dran rumzubehandeln.
Ich denke, hier spricht man tatsächlich zutreffender von (Programmier-)Fehlern - "Ausnahme" wäre beschönigend.

"Höchstwahrscheinlich" - also die Möglichkeit, dass im Einzelfall eine der Exceptions unvermeidbar ist, besteht - ist aber unwahrscheinlich.

Aber erstmal sollerdoch bitte gucken, wies zur ungültigen Konvertierung kommt, oder zum Zugriff ausserhalb der Grenzen einer Auflistung - das sollte doch wirklich vermeidbar sein.
Auch beim RechteKonflikt soller gucken, wieso sein Proggi mit einer Datei was anstellen will, wasses nicht darf. Ob etwa ProgrammDateien im falschen Ordner abgelegt werden, oder ausführbare Dateien manipuliert werden sollen, während sie aktiv sind. Oder das Prog ist selbst die Sperrungs-Ursache (tritt bei falsch implementierten Bild-Datei-Bearbeitungen gerne auf)

@Niko:
Nichtwahr: Erst am konkreten Beispiel kann man u.U. belegen, ob ein TryCatch angemessen ist, oder wie einfach er vermeidbar wäre.

Dein funktionierender TryCatch ist aber auch unzureichend, denn es können weitere Fehler auftreten, ungültige BildDateien und sowas.
Vor allem soll mit dem Img ja was gemacht werden, und das muß deaktiviert werden, wenns Img nicht geladen werden konnte.

Und die Deaktivierung kann erst programmiert werden im Zusammenhang mit der Gesamt-Anwendung: Soll dann ein Ersatzbild gezeigt werden? FehlerBild? Ist ein vorheriges Bild da, was dann bestehen bleiben soll?

Also eine funktionierende Fehlerbehandlung kann erst sehr spät überhaupt in Angriff genommen werden, nämlich wenn die Anwendung schon weitgehend ausprogrammiert ist.
Bis es soweit ist, sind die Exceptions. die fliegen dürfen, die besten Freunde des Entwicklers, bei seim Bestreben, eine sichere Anwendung zu proggen.

ErfinderDesRades schrieb:

gleich 5 Schrott-Beispiele

@EDR ich glaube Du vergallopierst Dich gerade

Beispiel TcpClient:

VB.NET-Quellcode

1. ' connect client
2. Try
3. client.connect(ipEndPoint)
4. catch ex as SocketException
5. ' client steht nicht zur verfügung
6. Finally
7. ' unmanaged resources
8. End try

Soll ich in einem Chat das Programm abbrechen nur weil 1 Teilnehmer nicht zur Verfügung steht ? Oder auf Async gehen ?

Beispiel TcpClient stream.Readine

VB.NET-Quellcode

1. Try
2. input=streamReader.readline
3. Catch ex as ioException
4. ' Verbindung abgerissen
5. Finally
6. ' close streams
7. End Try

Dass eine Verbindung von einem der Teilnehmer beendet wird ist wohl der Normalfall. Soll ich bei einem blockenden Read auf Async gehen um die Exception zu umgehen ?

Beispiel HttpWebRequest:

VB.NET-Quellcode

1. Try
2. ' request absetzen
3. Catch ex as WebException
4. ' statuscode analysieren, bei Session Timeout neu einloggen
5. Finally
6. ' close all streams
7. End Try

Macht es nicht Sinn sich bei Sessionende neu einzuloggen ? Oder bei einem Proxyfehler die Proxyadresse zu wechseln ? Oder ist es contextabhängig problematisch wenn 1 Adresse nicht erreichbar ist ?

Und das sind nur Beispiele wo die Exception schon in demselben Modul behandelt werden kann, Picos Beispiele geben die Entscheidung eher an übergelagerte Module weiter. Selbst wenn es im Katastrophenfall einmal nicht möglich ist auf eine definierte Situation zurückzugehen, so asollte man Exceptions imho verwenden um
- Rollbacks auszulösen
- unmanaged Resourcen zu schliessen
- Ausnahmen zu loggen

Niko Ortner schrieb:

Meine persönliche Meinung: Ich bin noch nie auf eine Situation gestoßen, bei der ich Try-Catch wirklich benötigt hätte.

Sry, aber dann liegt das vermutlich an Deiner persönlichen Situation. Ein intelligentes Exceptionhandling ist das A&O bei ausgereiften Applicationen. Oft ist es halt auch eine Frage des verhältnismässigen Aufwands: in Deinem beispiel mit der Textbox ist es sauberer und performanter es mit TryParse zu lösen, Exceptions kosten Overhead. Auf der anderen Seite kann ich mich im Vorfeld auch zu Tode prüfen (Bsp: Ping an einen Webserver), da ist eine Exception effizienter

Kangaroo schrieb:

ich glaube Du vergallopierst Dich gerade

sehe ich nicht so.

So abstrakte Beispiele sind nutzlos, weil sie die eigentliche Behandlung nur behaupten, nicht zeigen.

Damit lassen sie den Anfänger genau da im Regen stehen, wos schwierig wird.

@ErfinderDesRades: Bevor wir an uns vorbei reden: Worauf beziehst Du dich genau mit "Nichtwahr", denn

Erst am konkreten Beispiel kann man u.U. belegen, ob ein TryCatch angemessen ist, oder wie einfach er vermeidbar wäre.

so sehe ich das eigentlich auch.

Und @Kangaroo:

so asollte man Exceptions imho verwenden um ...

bzw. @ErfinderDesRades:

Soll dann ein Ersatzbild gezeigt werden? FehlerBild? Ist ein vorheriges Bild da, was dann bestehen bleiben soll?

Das war das, was ich mit "einem gezielten Beenden des Programmes" gemeint habe.
Solche Dinge sind wie von ErfinderDesRades erwähnt erst "im Zusammenhang mit der Gesamt-Anwendung" und "wenn die Anwendung schon weitgehend ausprogrammiert ist" festlegbar.
Wäre ja auch doof eine feste, immer gültige Norm zu haben, damit bei umfangreichen Bildprogrammen wie Adobe Photoshop nur "Fehler: System.ArgumentException" in einer MessageBox erscheint und das Programm sofort verschwindet.
In diesem Zusammenhang kann man wohl sagen "Kein Programm ist wie das Andere"

Edit: So ist es. Das "gezielte Beenden des Programmes" kann ja auch niemand im Forum wissen, weil niemand das Programm kennt.
Hier würde es sich anbieten nicht nur ein Beispielcodeschnipsel zu posten, sondern auch einen etwas umfangreicheren Code mit Angaben über das Programm (z.B. "Angenommen Du hättest ein Bildbearbeitungsprogramm und möchtest eine Datei öffnen, ...")

ErfinderDesRades schrieb:

gleich 5 Schrott-Beispiele

Nö. Die zeigen nur auf einfache Weise, dass man als Programmierer halt nicht in einem luftleeren Raum agiert. Das eigene Programm läuft immer in einer Umgebung, auf die man nicht wirklich Einfluss hat. Und jedesmal das Programm zu crashen, nur weil etwas "unerwartetes" passiert, scheint mir persönlich kaum eine gangbare Alternative zu sein.

EDIT
btw:

Und jeden, der TryCatch falsch einsetzt, als Idioten zu bezeichnen ist IMO bischen strong.

Das Problem ist, dass DU das (implizit) machst. Deine Aussage ist im Prinzip: Verwende keine Exceptions, denn du machst es im Zweifel sowieso falsch.
Übersetzung: Du bist ein unverbesserlicher Idiot.

WENN man postulieren würde "Wer Exceptions nur verschluckt, ist (von Ausnahmen abgesehen) ein Idiot.", dann wäre das im Prinzip korrekt, aber immer noch kein Argument gegen Try-Catch (höchstens eins gegen programmierende Idioten). Und selbst einem (vielen?) Idioten kann man beibringen, wie ein halbwegs "korrektes" Exception-handling auszusehen hat.

Back to Topic bitte

MemoAnMichSelbst schrieb:

Back to Topic bitte

Sind wir immer noch:

Londi schrieb:

Weis aber nicht genau was man damit macht

Einige (wenige) sind der Meinung, dass man am besten gar nix damit macht, weil sie eh zu nix nütze sind. Andere sind der Überzeugung, dass man sie zum Schreiben von sauberen und verwendbaren Programmen einsetzt.

Wobei Einigkeit darüber herrscht, dass:

NICHT zu den bevorzugten Einsatzweisen von Try-Catch gehört.

@picoflop
Ich glaube du siehst das ein bisschen falsch, ich denke was ErfinderDesRades damit sagen will ist, dass du als Profi natürlich try catch benutzen kannst, aber einem Anfänger zu raten try catch zu verwenden (aus bei sockets undso...) wäre falsch, denn sonst kommt er gar nicht auf die Idee bei der Programmentwicklung irgendwelche Fehler zu beheben, sondern baut einfach ne try catch drum.
Bsp. Man baut eine einfache "For i = 0 To ListBox1.Items.Count" und lässt sich alle Items ausgeben. Du siehst natürlich: Klar das gibt nen Fehler da fehlt die -1 hinter dem Count. Der Anfänger sieht das aber nicht sofort, baut nen try catch drum und meint es ist damit gut.

Ich würde auch eher sagen während der Entwicklung try catch vermeiden (aus bei sockets undso...) und eher am ende, wenn das Programm gut läuft try catch einbauen um alle so zu sagen von außen einwirkenden Fehler zu fangen.

picoflop schrieb:

Einige (wenige) sind der Meinung, dass man am besten gar nix damit macht, weil sie eh zu nix nütze sind.

Wer ist denn dieser Meinung?

Also meine Empfehlung ist, Ausnahmen nur dann zu fangen,

1. wenn man sie auch behandeln kann
   
2. wenn durch sauberes Code-Design nicht möglich ist, das Auftreten auszuschließen
   
3. oder halt 2 Sonderfälle:
   • "graceful exit" - um die Anwendung sauber zu schließen, ohne dem User Programm-Interna zu präsentieren. (Diese Art Behandlung liegt relativ nahe der Behandlung, die die Runtime auch automatisch ausführte. - nebenbei: wieso meinen die Leute eiglich, ein "Absturz" sei keine Ausnahmebehandlung?)
     
   • ReThrowing: nicht behandeln, sondern die Exception durch Wrappern in eine weitere Exception mit Information anreichern
     
   
   

Tatsächlich glaube ich nicht, dass du oder Kangaroo es in der Praxis anders handhabt, wohl aber die 90% VBP-User, denen die HauptWirkungen eines TryCatches nicht ausreichend klar sind - nämlich:

1. zur DesignZeit ist im Try-Abschnitt der Debugger deaktiviert
   
2. das Programm darf weiter-laufen
   

Natürlich sind diese Wirkungen "bekannt", aber was das in ganzer Tragweite bedeutet, ist ihnen unklar:

1. Der Code im TryCatch hat standardmäßig "Narrenfreiheit" (wiegesagt: Non-Noobs schränken die als erstes sogutesgeht ein, aber halt nur die Non-Noobs). Diese Narrenfreiheit ist ein erhebliches GefahrenPotential - selbst Profis schreiben gelegentlich die eine oder annere Zeile Narren-Code
   
2. Das Weiterlaufen nach unzureichender Behandlung bedeutet im Klartext: Das Prog läuft in undefiniertem und instabilem Zustand weiter.
   Und das ist ungefähr die größte Katastrophe, die man überhaupt einprogrammieren kann.
   

Die Crux ist: ...nur, wenn man die Exception behandeln kann.
"Behandeln" bedeutet nämlich fast immer einen erheblichen bis enormen Aufwand.
Und zwar bei doppelter Sorgfalt, denn sonst crashtes immer noch, oder es kommt zu irreführenden FehlerMeldungen und sowas (zB die USB-Stick-Meldung darf nur dann kommen, wenn 100% gesichert ist, dass nirgends ein Stick steckt).

Auch ist eine Behandlung meist ühaupt erst möglich, wenn die App weitgehend ausprogrammiert ist. Erst dann kann eine User-Interaktion implementiert werden, um überhaupt die Parameter des ReTrys zu klären.
Bis die App aber soweit ist, empfehle ich die Bedingung wirklich ernst zu nehmen: nicht, wenn man nicht behandeln kann.
Ansonsten behält man ziemlich wahrscheinlich halbfertige TryCatch-Leichen drinne, von zombi-mäßiger Rachsüchtigkeit ;).

hallo erstmal!
So viele Antworten, ich danke euch!
Was soll ich jetzt machen, oder nicht machen?

(P.S. Kann mir jemand ein gutes tut., für Anfänger geben?)

Komische Frage.
Deine Thread-Eröffnung frug nach Erläuterungen zu TryCatch, und da bist du IMO reichlich bedient worden ;).
Im engsten Snne war deine Frage bereits mit post#2 beantwortet, die weitere Diskussion beleuchtet aber IMO wichtige Aspekte.

Was du "machen sollst" kann dir hier aber glaub nicht gesagt werden.

Ich wüsste auch kein Tut über TryCatch, weil das ist halt ein einzelnes Sprach-Element.
Für For Each gibts ja auch kein Tut (oder irre ich mich?)

Wer ist denn dieser Meinung?

->

Hmm - niemand meldet Fehler besser als die IDE selbst, wenn man sie nicht (durch TryCatch) daran hindert:
Meldung, Codestop, Fehlerzeile gelb markieren, Werte aller Variablen im Lokal-Fenster einsehbar - was will man mehr?
Selbst die Release-Version einer Anwendung meldet Fehler mit bestmöglicher Differenzierung.

Nachsatz: Und schmiert direkt im Anschluss gnadenlos ab.

Londi schrieb:

Was soll ich jetzt machen, oder nicht machen?

Denken ...
WO kann etwas schief gehen (ohne dass du Einfluss darauf hast) und WAS soll passieren, WENN etwas schief geht?

Entwicklerbuch
ab S. 344

Was soll ich jetzt machen, oder nicht machen?

Ich pauschalisiere jetzt mal und sage, dass Du Try-Catch vorerst nicht verwenden solltest.
Es hat auch einen gewissen Lernfaktor, wenn Du siehst welche Exceptions bei manchen Vorgängen geworfen werden.
Wenn Du das verstehst und begreifst wie weitreichend die Entscheidung einen Try-Catch Block einzubauen ist, dann kannst Du (in sinnvollen Situationen) sowas einbauen.

Edit: Wie ErfinderDesRades erwähnte: "da bist du IMO reichlich bedient worden"

Edit2: "Und schmiert direkt im Anschluss gnadenlos ab"
Da müsste man dann das "gezielte Beenden des Programmes" einbauen. Und das ist wie bereits erwähnt erst "im Zusammenhang mit der Gesamt-Anwendung" und "wenn die Anwendung schon weitgehend ausprogrammiert ist" möglich.

picoflop schrieb:

Wer ist denn dieser Meinung?

->

Hmm - niemand meldet Fehler besser als die IDE selbst, wenn man sie nicht (durch TryCatch) daran hindert:
Meldung, Codestop, Fehlerzeile gelb markieren, Werte aller Variablen im Lokal-Fenster einsehbar - was will man mehr?
Selbst die Release-Version einer Anwendung meldet Fehler mit bestmöglicher Differenzierung.

Nachsatz: Und schmiert direkt im Anschluss gnadenlos ab.

Das ist jetzt aber ein durch Rausreißen aussm Zusammenhang böse sinn-entstelltes Zitat - hier nochmal im Zusammenhang: AvoidTryCatch

Aber auch so herausgerissen steht da nicht: "TryCatch ist zu nix nutze".
Sondern das ganze steht unter der Überschrift "Vermeide TryCatch" - und das hat eine annere Bedeutung als "TryCatch ist dirty".

Hallo zusammen!
Ich möchte mich den Meinungen von EDR und Niko anschließen (auch, wenn die Erfahrung noch nicht so weitreichend ist wie Eure).
Bei meinen paar Progrämmchen kann ich mich nicht erinnern groß mit TryCatch gearbeitet zu haben, denn, wie hier bereits mehrfach geschrieben, gibt es fast immer die Möglichkeit es sauber zu "coden".

Ich wünsch allen nen schönes WE

dolce schrieb:

gibt es fast immer die Möglichkeit es sauber zu "coden".

Nein. Denn "sauberes coden" kann eine "Umweltänderung" nicht ausschließen oder vorhersagen. Wie im wirklichen Leben sind Veränderungen der Umwelt allerdings kein Grund, gleich Selbstmord (Application.Crash) zu begehen.
Außerdem - dir fehlt halt die Erfahrung - gibt es bestimmte Exceptions, die "gewollt" sind. PingException? ThreadAbortException? EndOfStreamException etc.