Hallo Leute,
Ich sehe noch oft diese "try" (versuchen) Funktion. Weis aber nicht genau was man damit macht, geschweige denn, es an zu wenden.
Kann mir jemand helfen?

msdn.microsoft.com/de-de/library/fk6t46tz.aspx

danke

nochn Tip: Versuch zu vermeiden, Exceptions zu fangen. AvoidTryCatch

Wobei merkwürdigerweise mancher Code schneller ausgeführt wird, wenn er in einem Try...catch-Block liegt (laut mehreren Threads auf z.B. stackoverflow).

ErfinderDesRades schrieb:

nochn Tip:

nochn Tip von mir: Hör nicht auf Leute, die dazu raten, Exceptions NICHT zu catchen ...

picoflop schrieb:

nochn Tip von mir: Hör nicht auf Leute, die dazu raten, Exceptions NICHT zu catchen ...

/sign lerne dafür aber die Dinger richtig und zum richtigen Zeitpunkt zu catchen: das globale und alles abfangende Try .. Catch ex as Exception führt wirklich zu heftigen Problemen, da es von der NullDivision bis zur ColaInDerTastatur wirklich alles unterdrückt.

Ausnahmsweise verlinke ich mal auf eine Diskussion in einem alten Beitrag , wo wir auch über dieses Thema diskutiert hatten.

Ich frag mich ja auch immer, warum manche Leute glauben, dass eine Exception einen Fehler bedeutet?
Exception übersetzt ist AUSNAHME. Eine Ausnahme ist KEIN Fehler per se!
Eine Ausnahme(situation) erfordert eine andere Behandlung (exception handling ... anyone?) als eine STANDARDsituation. Das wars aber auch schon.
Möchte mal sehen, wie jemand einen Task - den Regeln entsprechend - durch setzen des CancellationTokens abbricht, OHNE dass eine ThreadAbortedException ausgelöst wird.

najaa - immer dieselbe Leier.
Wenn einer was coden kann, dass die Anwendung sicher weiterlaufen kann, obwohl eine Exception geflogen ist, dann kannerse natürlich fangen. Nur ist dieser Fall ziemlich selten. Genau das ist in meim Statement ja am Beispiel gezeigt, wie schwierig bis unmöglich es in den meisten Fällen ist.

Allein durch Ausgabe einer Meldung jedenfalls ist kein Problem gelöst, sondern die App läuft weiter, und zwar mit dem Problem (und das ist dann ein viel gravierenderes Problem).

Ich rate nicht prinzipiell vom Fangen ab, sondern sage: "Vermeide es", und da ist der Königsweg, halt sicher zu proggen, sodass keine Exception auftritt.

Und man fange sie nur, wenn man sie sinnvoll behandeln kann - naja - auch schon gesagt: kommt auf den Einzelfall an, ob überhaupt möglich ist, sie zu behandeln.
Und wenns nicht möglich ist, muß die App geschlossen werden (weil sie wird eh an der nächsten Ecke crashen).

ErfinderDesRades schrieb:

Nur ist dieser Fall ziemlich selten.

Quatsch, das ist der Normalfall.
Und in den seltenen (!) Fällen, wo ein Programm nach einem Fehler nicht weiterlaufen kann/soll, muss man im Zweifel immer noch abfangen und handlen -> Stichwort: graceful exit !

ErfinderDesRades schrieb:

najaa - immer dieselbe Leier.

Sorry, aber das ist (ausnahmsweise) von Dir zu billig: versuch mal mit Sockets / TcpClient zu programmieren ohne Exceptions abzufangen. Das ist wie Pico schreibt wirklich der Normalfall.

Wie in der alten Diskussion argumentiert: unterscheide zwischen Standard- und Ausnhamefällen. Weiterhin: auch für eigene Custom Exceptions , wie willst Du bequemer den Kontrollfluss unterbrechen und bis zu einer Ebene hochreichen die sich kompetent erklärt die Ausnahme zu behandeln ?

@Picoflop Stichwort Graceful Exit: z.B. ist es sinnvoll beim Mitlaufen eines Logs auch unhandled Exceptions mittels AppDomain Event abzufangen und zu loggen. Dann erst Application.Exiit ..
@jvbsl nie bestritten

es heißt nur, man soll wenn möglich nicht per Try Catch alles fangen.
Vorallem nicht so:

Nun wird nämlich absolut jeder Fehler gefangen...

Und du wirst mir doch zu stimmen, dass es wohl sinnvoller ist das hier zu machen(auch lesbarer):

Als das hier:


Es geht denke ich vorallem darum, dass viele dann ewig den Fehler suchen, obwohl dieser von einem Try-Catch Block abgefangen wird...

Performancetechnisch brauchen Exceptions auch nicht wirklich viel...

jvbsl schrieb:

Try Catch alles fangen.

FANGEN ist die ERSTE Stufe. Danach muss man dann entweder "behandeln" oder "verschlucken" (swallow).
Und nein, im Normalfall soll man Exceptions nicht einfach "schlucken". Denn irgendwas muss man ja tun. Und wenn es eine "Datei nicht gefunden, bitte Pfad prüfen und erneut versuchen" Meldung ist.

Das hat aber nix mit Avoid-try-catch zu tun. wer atc propagiert lebt in einer Scheinwelt. imho.

Also hier im Forum habich andie hundert TryCatchens gesehen, und einzig bei der UnAuthorisizedException war die Behandlung meist vertretbar, nämlich sie zu verschlucken.
An kein weiteres Beispiel erinnere ich mich in meiner "Scheinwelt".

Kangaroo verlinkt ja auch auf sone Gurke, aber man kann glaub sogar die ForenSuche betätigen, um sich selbst zu überzeugen: vb-paradise.de/index.php?form=…D=1385497&highlight=Catch
Also ich hab jetzt die ersten 5 Treffer mit Codebeispiel nachgeguckt - ausnahmslos Schrott.

Ihr könnt ja mal weitersuchen, ob ihr auch vertretbare Beispiele für Catchens findet, und dann mal in Relation zu den Gurken setzen, und dann reden wir nochmal über "Scheinwelt", und übers Hören auf die, die dazu raten, TryCatchens nur äußerst vorsichtig einzusetzen.

Es ist doch ganz einfach:
du propagierst: avoid try catch
Wenn du meinst "avoid try catch, if you are an idiot", dann solltest du das klar sagen.

In einem SAUBER geschriebenen Programm (und wir gehen davon aus, dass es Ziel dieses Forums ist, dass mehr davon entstehen?), ist Try-Catch omnipräsent! Es gibt praktisch keinen Bereich, in dem nicht, vom Programmierer unbeeinflussbare, Exceptions auftreten können. Und in den allermeisten Fällen, ist die Behandlung dieser Ex möglich. Und selbst wenn diese NICHT möglich ist (Out of Memory Exception KANN fatal sein, muss aber nicht), sollte man es zumindest VERSUCHEN.

Wie jetzt - soll es etwa weiterlaufen, wenn eine Daten-Anforderung (oder ein vergleichbarer Ressourcen-Zugriff) fehlschlägt? - Es muss crashen!

Völliger und totaler Blödsinn. In den allermeisten Fällen ist eine Exception ein singuläres, temporäres Ereignis. Und überdies meist oft abstellbar.
Zugriff auf die Datenbank schlägt fehl? So what? Netzwerkkabel wieder rein und es geht wieder. Dazu muss man nicht gleich die Anwendung abschießen.

Try-Catch macht Sinn bis zu einem gewissen Grad. Und zwar genau dann wenn es auch durch sauberen Code nicht vermieden werden kann. (z.B. Sockets... usw.)
Was in dem Forum jedoch sehr sehr oft gesehen wird ist, dass dieser Try-Catch Block als Rezept für jeden Runtimefehler gesehen wird. Sprich wenn irgendwo NullReferenceException auftritt ist von vielen der erste Schritt try-catch drum herum. Und das ist total falsch. Ich kann nicht jeden billigen Fehler durch try catch ersetzten weil dann hab ich nur noch try-catch im code --> ist bei manchen so.

ErfinderDesRades schrieb:

An kein weiteres Beispiel erinnere ich mich in meiner "Scheinwelt".

Sorry, Du lebst wirklich in einer Scheinwelt der Paradigmen: Do !/ Do Not ! Oder noch besser: Do what I say !

Das lässt keinen Raum für Nuancen. Die Thesen lauteten:
- Exceptions behandeln Ausnahmefälle, nicht notwendigerweise Fehler
- man lerne sie intelligent zu behandeln

Dafür gab es in der Diskussion genügend Argumente, auf die Du nur nicht eingehst. Mit Google-Treffern erschlägt man keine (hoffentlich) intelligente Argumentation. Genausowenig wird man glaubwürdiger wenn man nach 16 Minuten seinen Post editiert um seine Argumentation einzuschränken.

My 5 Cent ...

Bitte bringt Beispiele!

Ich habe einen Haufen praktische Beispiele gebracht, wo TryCatch unangemessen ist, nun bringt Gegenbeispiele, und wiederholt nicht am laufenden Band, dass TryCatch auch sinnvoll sein kann (was ich ja ühaupt nicht bestreite)

Und jeden, der TryCatch falsch einsetzt, als Idioten zu bezeichnen ist IMO bischen strong.
Die falsche Verwendung von TryCatch sieht man so extrem überwiegend, in Foren, WebCasts, Lehrbüchern, dass man als Anfänger schon sehr auf Zack sein muß, um von selbst auf die Brisanz dieses Mechanismus' zu kommen - denn kaum iwo wird das mal thematisiert.

Edit (19 Minuten ;)): An den Thesen habichnix auszusetzen. Nun bitte ein paar Beispiele

Nur in Kurzform:

if file.exists(foo)
try
a=file.readallline(foo)
catch
messagebox("Bitte USB Stick wieder einstecken")


try
con.open
catch
messagebox("SQL Server wird wohl gerade neu gestartet, bitte in 2 Minuten wieder versuchen


try
webclient.download(foo)
catch
messagebox("inet weg, soll ich es später nochmal versuchen?)


try
b=image.fromfile(foo)
catch
messagebox("sorry, aber für 1.5 GB große Bilddateien reicht der Speicher nicht")


try
httprequest.machwas
catch
messagebox("da ist wohl die session abgelaufen. soll ich mich neu anmelden?")


uswuswusw

ErfinderDesRades schrieb:

Bitte bringt Beispiele!

Haben wir doch, nur Du gehst partout nicht auf sie ein.

ErfinderDesRades schrieb:

Ich habe einen Haufen praktische Beispiele gebracht, wo TryCatch unangemessen ist

Dass Exceptions oft zu pauschal eingesetzt werden wurde nie bestritten, deswegen ja die Anmerkung man lerne Exceptions sinnvoll einzusetzen. Und um ein paar Thesen in Raum zu stellen hatte ich halt auf den alten Beitrag verlinkt, der keinen Anspruch auf Vollständigkeit erhebt. Nur: mit amerikanischen Slogans 'Avoid TryCatch' kann man in Amerika vielleicht Wahlen gewinnen , aber ansonsten/deswegen ist das totaler Blödsinn. Nebenbei: Du hast keinerlei Beispiele gebracht, sondern nur einen Forenlink präsentiert: der nebenbei auch noch in die Leere geht ...

ErfinderDesRades schrieb:

Die falsche Verwendung von TryCatch sieht man so extrem überwiegend, in Foren, WebCasts, Lehrbüchern, dass man als Anfänger schon sehr auf Zack sein muß, um von selbst auf die Brisanz dieses Mechanismus' zu kommen - denn kaum iwo wird das mal thematisiert.

Deswegen sollte man ja auch feinfühlig damit umgehen - oder ? Deswegen ja auch die Diskussion - und da sind Paradigmen wie 'Avoid TryCatch' nicht gefragt ....