Hallo!

Ich entwickle eine Anwendung, in der ich Geschäfts- und Präsentationslogik in zwei separaten Layern halte.

Der Präsentationslayer sollte sich ja nur mit der reinen Anzeige befassen. Soll ein neues Objekt (z. B. Produk) gespeichert werden, so reicht der Präsentationslayer die Daten an den Applikationslayer weiter. Geht jetzt irgendetwas schief, würde eine entsprechende Exception geworfen werden, die durch den Präsentationslayer behandelt und dem Benutzer gezeigt wird.

Erstelle ich jetzt für jeden Fehler eine eigene Exception? Dann braucht meine Anwendung ja später hunderte benutzerdefinierte Exceptions (z.B. kein Name angegeben, zu kurzer Name, Name schon vorhanden, Benutzer nicht berechtigt und und und). Oder mache ich eine einzelne Exception und gebe dieser noch einen Fehlercode oder -text mit?

Über Tipps und Anregungen würde ich mich freuen. Gibts da Best-Practices?

Gruß
Philip

Benutze unterschiedliche Exceptiontypen nur wenn du diese auch unterschiedlich behandeln willst.
Außerdem gibt es für viele Fälle bereits vordefinierte Exceptiontype. Deine ersten Beispiele könnte man zum Beispiel durch ArgumentOutOfRangeException darstellen.

Exception Hierarchy
Design Guidelines for Exceptions
Designing Reusable Frameworks Blog

Hallo

Für mich sind Exceptions Ausnahmen. Ob ein Text oder Zahl eingeben werden soll, ist für mich keine Exception, sondern sollte mit Programmierlogik abgefangen werden.
Ideal wäre wenn der User arbeiten kann ohne Fehlermeldung. Stell dir einfach vor du musst selber mit dem Ding arbeiten. 90% liest nie was in einer Meldung und wieviele sind es die lesen und erst noch verstehen der Programmierer gemeint hat?

Ich hasse Meldefenster quittieren.

lothi hat folgendes geschrieben:

Ob ein Text oder Zahl eingeben werden soll, ist für mich keine Exception, sondern sollte mit Programmierlogik abgefangen werden.

So eine Abfrage gehört natürlich in den UI-Code, keine Frage. Aber wie willst du Fehlermeldungen aus dem Business-Layer herausbekommen außer durch Exceptions? Für jede Property eine IsValidValueForXYZ-Methode zu schreiben, ist wohl nicht so ganz das Wahre . Und WPF macht das Ganze mit der ExceptionValidationRule schon fast zu einfach.

lothi hat folgendes geschrieben:

Ideal wäre wenn der User arbeiten kann ohne Fehlermeldung.

Ja, das wäre das Optimum. Aber egal ob Exceptions oder ifs - wenn das eingegebene Passwort zu kurz ist, muss ich das wohl irgendwie anzeigen .

Kha hat folgendes geschrieben:

lothi hat folgendes geschrieben: Ob ein Text oder Zahl eingeben werden soll, ist für mich keine Exception, sondern sollte mit Programmierlogik abgefangen werden. So eine Abfrage gehört natürlich in den UI-Code, keine Frage. ...

Einspruch. Die Konstistenz des Models sollte vom Model geprüft werden und nicht ~zufällig~ erfüllt sein weil die UI das eingeben falscher Daten nicht zulässt oder selbst handelt.
Mann kann diese Prüfung/Eingabeeinschränkung zusätzlich in der UI machen, und für eine gute UI ist das auch sicherlich Pflicht, aber auf auf keinen Fall ersetzt diese die Prüfung im Model.

@lothi : Exceptions sind keine Programmierlogik

Primär ging es mir um diese Aussage.

Zitat:

Dann braucht meine Anwendung ja später hunderte benutzerdefinierte Exceptions (z.B. kein Name angegeben, zu kurzer Name, Name schon vorhanden, Benutzer nicht berechtigt und und und).

Solche Sachen würde ich jetzt nicht mit Exception abarbeiten, sondern versuchen zu verhindern das man so etwas überhaupt eingeben kann und oder den User optisch aufmerksam machen das etwas nicht stimmt.

Meine Vorstellung:
Wenn die Klasse eine string Eigenschaft erwartet, würde die Prüfung in der UI machen. Bekommt die Eigenschaft keinen String soll die Klasse eine Exception werfen, was aber der Entwickler ausbaden soll und nicht später der User.
Wenn aber überprüft werden muss ob der Eintrag vorhanden ist, soll das die Klasse erledigen und dann verständlich zurückmelden.


Gruss Lothi

Ralf Jansen hat folgendes geschrieben:

Mann kann diese Prüfung/Eingabeeinschränkung zusätzlich in der UI machen, und für eine gute UI ist das auch sicherlich Pflicht, aber auf auf keinen Fall ersetzt diese die Prüfung im Model.

Wenn ich im Business-Objekt eine int-Property habe, dann ist das doch hoffentlich Prüfung genug, dass nichts Anderes als ein int hereinkommt . Es ging mir nur um dieses eine Beispiel, ansonsten stimme ich dir natürlich zu.

lothi hat folgendes geschrieben:

Solche Sachen würde ich jetzt nicht mit Exception abarbeiten, sondern [...] den User optisch aufmerksam machen das etwas nicht stimmt.

Muss sich das widersprechen ? Noch einmal Beispiel WPF: Meine TextBox ist an User.Name gebunden. Sobald der Benutzer ein Zeichen eingibt (oder wahlweise erst, wenn er die TextBox verlässt), wird die Property gesetzt, wirft eine ArgumentException("Benutzername bereits vergeben") und der Benutzer bekommt einen kleinen roten Text unter seine TextBox. Und das Ganze ohne eine Zeile UI-Code (außer ein wenig XML).
Selbst wenn man jetzt für den UI-Code eine IsUserNameAvailable-Methode einführen würde, muss die Prüfung mit der ArgumentException drin bleiben, wie Ralf Jansen schon gesagt hat, denn der Business-Layer hat keine Garantie dafür, dass die Methode von der GUI wirklich aufgerufen wurde. Bevor ich das zweimal programmieren muss, bleib ich doch lieber bei Exceptions .