Hi Leute,
mich würde mal interessieren, wie ihr exceptions einsetzt.
Ich gehe immer noch sehr sparsam damit um, Exceptions selbst zu werfen. Ich programmiere z.B. gerade eine Funktion, die in ihrer Ausführung in bestimmt fällen schiefgehen kann. Ich könnte nun entweder Exceptions werfen, wenn die Funktion schief geht, oder mit einem InsecureResult arbeiten, welches mir das eigentliche Result kapselt und mit einem Status koppelt.
Wie würdet ihr vorgehen ?
Gruß
Christoph
Exceptions sind dazu da Faults zu melden. In Java kommt das noch besser rüber durch die checked Exceptions.
Aber generell handhabe ich das immer so:
Umso tiefer in der Applikation drinnen umso mehr Exceptions fliegen, umso näher beim User umso näher muss die Applikation Fehlverhalten abfangen.
Aber irgendwelche Return-Werte halte ich für den falschen Weg. Wir programmieren ja mit C# und nicht mit C.
As a man thinketh in his heart, so he is.
Ich werfe in jedem Fehlerfall exceptions, einzige Außnahme ist wenn ein "Fehler" mit einer hohen Warscheinlichkeit auftritt (und somit eigentlich keine Exception, zu deutsch Außnahme ist) dann mache ich zusätzlich noch eine TrySometing Methode dazu.
Vorteil von Exceptions ist dass in jedem Fall ein Fehler auftritt und nicht nur wenn derjenige der die Funktion verwendet und gründlich die doku (falls vorhanden ^^) gelesen hat. Außerdem kann man durch inner exception das ganze detailierter machen und durch den stacktrace genau feststellen wo der fehler auftrat.
Hallo Christoph K.,
bitte nicht schon wieder! Das haben wir doch nun oft genug gesprochen. Außerdem steht das in jedem guten C# Buch (und es gibt sicher auch viele gute Blog-Artikel dazu).
Siehe zum Beispiel (nur eine erste Auswahl, mehr über die Forensuche):
Rückgabe von Methoden: Ergebnis, falls erfolgreich, Fehler sonst. Wie am besten?
Best Practice: Exceptions
Für jeden Fehler eine eigene Exception?
Exceptions: Welche gibt es alles? Welche kann/muss man abfangen?
Exception Behandlung/Dokumentation
Wie sollte man einen Fehler benennen?
Natürlich sollten Exceptions, wie der Name sagt, nur in Ausnahmefällen geworfen werden. Aber ist es genauso klar, wenn du Klimmzüge machen musst, um auf Biegen und Brechen das Werfen von Exceptions zu vermeiden und erst recht, wenn du Fehlerinformationen in Rückgabewerte reinquetschen willst, bist du auf dem Holzweg.
herbivore
Zuerst mal. Zu dem Thema ist hier alles gesagt. Auf jeden Fall.
Die Frage ob Exception oder Rückgabewert bleibt im Einzelfall immer diskusionswürdig. Ich hatte schon mehrfach die Diskussion bei Login Methoden.
LoginFailedException oder false? Während Java Programmierer immer mehr zu Exceptions neigen würden C# Programmierer vielleicht mit C oder C++ Background vielleicht! eher zum Rückgabewert neigen habe ich erfahrungsweise
festgestellt.
Die Frage ist möchte ich Exceptions werfen um Fehler in der BusinessLogic zu signalisieren(z.b. Kreditrahmen überschritten bei einer Bankanwendung) oder nur für technische Fehler. Diese Frage muss man für sich klären.
Danach muss man dem ganzen nur noch folgen, so deute ich auch deine Eingangsfrage. Und jetzt wirds interessant, es kommt meiner Meinung nach auf die Schicht an in der du dich bewegst. Eine WindowsFormsAnwendung zur reinen Anzeige sollte sauber designt keine eigenen Exceptions werfen, sondern nur technische. Hier ist auch das brechen der Regel "do not catch general exceptions" ausnahmsweise mal erlaubt Eine BusinessLogic Dll quasi eine andere Schicht dahinter darf jedoch eigene Exceptions zu Fehler in der Logik definieren und auslösen(sowie z.b. überschreiten des Kreditrahmens) . Soweit meine Meinung.
(Eine LoginFailedException wäre also okay... wenn sie von der richtigen Schicht kommt.)
Eine BusinessLogic Dll quasi eine andere Schicht dahinter darf jedoch eigene Exceptions zu Fehler in der Logik definieren und auslösen(sowie z.b. überschreiten des Kreditrahmens) . Soweit meine Meinung.
Und genau das sollte sie nicht tun.
Wir hatten dieses Thema auch schon mal im Zusammenhang mit DataBinding.
Das DataBinding "verschluckt" gerne mal solche Exceptions, und dann hat man nichts gewonnen.
Für sowas sollte man IDataErrorInfo benutzen.
Also bevor man eine Exception wirft, sollte man immer schauen, ob es nicht im FW einen Standard Weg gibt.