Laden...

Wie setzt ihr Exceptions ein?

Erstellt von Christoph K. vor 13 Jahren Letzter Beitrag vor 13 Jahren 1.964 Views
Christoph K. Themenstarter:in
821 Beiträge seit 2009
vor 13 Jahren
Wie setzt ihr Exceptions ein?

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 ?

  • Exception ruhig nutzen, auch um Fehler bzw. Verhalten zu kommunizieren?
  • Exception nur bei harten Fehlern werfen?

Gruß
Christoph

799 Beiträge seit 2007
vor 13 Jahren

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.

  • Jun Fan
    Es gibt nichts Gutes, außer man tut es.
  • Erich Kästner
    Krawutzi-Kaputzi
  • Kasperl
D
33 Beiträge seit 2010
vor 13 Jahren

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.

49.485 Beiträge seit 2005
vor 13 Jahren

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

Gelöschter Account
vor 13 Jahren

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

F
10.010 Beiträge seit 2004
vor 13 Jahren

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.