[Sammlung] Sinnvolle Verwendungen für Try-Catch

Vielleicht liegt es ja an der Build-Konfiguration. Hab Ihr es auf Debug oder auf Release? AnyCPU?

ohne jetzt alles durchzulesen würde ich sagen bei webrequests bei verbindungsabbruch

@thefiloe: Soetwas schon eher. Das sind einfach Sachen, auf die der Entwickler keinen Einfluss haben kann. Und dafür ist Try-Catch eigentlich gedacht.

is natürlich auch nur die halbe Miete (und zwar die zweite Hälfte ;)).
Vorher muß ja bereits etwas programmiert sein, was dann ersatzweise passieren soll, wenn der WR seinen Job nicht tut.

Interessiert mich jetzt trotzdem, warum das bei euch geht

- bei WMI-Abfragen
- beim ReaderWriterLock für das TimeOut
- bei Socketprogrammierung im Allgemeinen eigentlich immer erforderlich
- bei DateiLeseZugriff, im speziellen XML-Dateien zB per Deserializer oder DataSet.ReadXml laden

Mono schrieb:

- bei WMI-Abfragen

wieso besonders da?

- beim ReaderWriterLock für das TimeOut

/sign

- bei Socketprogrammierung im Allgemeinen eigentlich immer erforderlich

ähm - in VersuchsChat zeigt sich, dass im Server nichtmal eine Exception fliegt, wenn ein Client mittm Taskmanager abgeschossen wird.
Also es bezöge sich auf VerbindungsAbbruch während Datenübertragung - das konnte ich nicht testen

- bei DateiLeseZugriff, im speziellen XML-Dateien zB per Deserializer oder DataSet.ReadXml laden

Selbes Prob wie in Post#25: Solange noch nix geproggt ist, wies ühaupt weitergehen soll, wenn der Zugriff fehlschlägt, solange täte ich davon abraten, einen TryCatch hinzuschreiben.

Jo, deinen Versuchschat habe ich mir angeschaut.
Und was Fehlerbehandlung angeht ist der leider nicht besonders gut.

Starte doch einfach mal den Server und Client und deaktiviere deine Netzwerkkarte oder zieh das Kabel.
Oder gib ne falsche IP ein beim Server.

Selbes Prob wie in Post#25: Solange noch nix geproggt ist, wies ühaupt weitergehen soll, wenn der Zugriff fehlschlägt, solange täte ich davon abraten, einen TryCatch hinzuschreiben.

Das ist ja wohl klar...

Mono schrieb:

Und was Fehlerbehandlung angeht ist der leider nicht besonders gut.

naja, VersuchsChat is haltn VersuchsChat zum Rumprobieren mit TCP, und keine Release.
Da schadet es ühaupt nix, wenn man auch Fehler provozieren kann - das gehört zum rumprobieren.

Dies war keine Kritik an dem Chat ansich oder ähnliches.
Bitte nicht falsch verstehen.

Aber:

ähm - in VersuchsChat zeigt sich, dass im Server nichtmal eine Exception fliegt, wenn ein Client mittm Taskmanager abgeschossen wird.

Hier bringst du diesen ins Spiel als Beispiel für "Try Catch ist unnötig".

Um dann doch zu sagen, dass in diesem Stadium noch kein Try Catch verwendet wird.

Allerdings sehe ich das grundsätzlich eher anders.
Hat man eine Komponente/Klasse fertig, dann gehört dazu auch eine fertige Fehlerbehandlung.
Das geht von Try Catch, wenn es nötig ist, bis hin zu eigenen Exceptions.

Ich fang doch nicht an, in einem großen Projekt mir Klassen zu entwerfen und zu entwickeln, welche dann irgendwann an irgendeiner Oberfläche bedienbar etc sind und fang DANN erst an, wieder jede Klasse durchzuarbeiten und eine Fehlerbehandlung hinzuzufügen.
Ich überlege mir gleich, welche erwartbaren Fehler können durch andere, verwendete Klassen geworfen werden.
Diese muss ich behandeln und entsprechend meine Logik etc entwickeln.
Danach überlege ich mir, welche Fehler können, durch falsche Übergabeparameter oder was auch immer, innerhalb meiner Klasse entstehen, wenn diese von woanders aufgerufen und verwendet wird.
Über Exceptions und Try Catch kann man genau definierte Fehler behandeln und auch selber verwenden.

Ein Beispiel:

Irgendeine Funktion gibt normalerweise ein Objekt zurück.
Es sei denn, einer von 3 erwartbaren Fehlern tritt auf.
In irgendeiner Form muss ich der aufrufenden Instanz den Fehler mitteilen.
Eine Variante wäre:
Rückgabewerte sind int. 0 ist OK und alle Fehler haben einen Code.
Der eigentliche Rückgabewert wird als Out Parameter zurückgegeben.

Diese herangehensweise ist .. nunja.. sagen wir, leicht aus der Mode.

Alternativ bekomme ich meine Rückgabe tatsächlich als Rückgabewert der Funktion oder eine bestimmte, behandelbare Exception pro Fehlerart wird geworfen.
Was genau ist daran denn verwerflich ?

Mono schrieb:

Ich fang doch nicht an, in einem großen Projekt mir Klassen zu entwerfen und zu entwickeln, welche dann irgendwann an irgendeiner Oberfläche bedienbar etc sind und fang DANN erst an, wieder jede Klasse durchzuarbeiten und eine Fehlerbehandlung hinzuzufügen.
Ich überlege mir gleich, welche erwartbaren Fehler können durch andere, verwendete Klassen geworfen werden.

Täte ich aber so empfehlen.
Weil - wie gesagt - solange die Oberfläche nicht steht, kann ein Fehler doch gar nicht behandelt werden.

Mono schrieb:

[eigene Exceptions werfen] ... Was genau ist daran denn verwerflich ?

Nix - Werfen ist nicht verwerflich.
Nur beim Fangen muß man aufpassen.

nikeee13 schrieb:

@thefiloe: Soetwas schon eher. Das sind einfach Sachen, auf die der Entwickler keinen Einfluss haben kann. Und dafür ist Try-Catch eigentlich gedacht.

Ja eben ist ja ein Sammelthread für Sinnvolle Verwendungen für Try-Catch blöcke.

mir ist noch eine eingefallen: Bei Cryptographie - Entschlüsselung kommts zu Fehlern, wenn der User das falsche Passwort eingibt.
Ich hab hier ein Sample aus Verschlüsseln + Autentifizieren, wo dann geschlossen wird aber wohl öfter wird man ein Retry programmieren (also 'ne Schleife drum machen).
(Crypter ist eine Hilfsklasse zur Erstellung von CryptoStreams)