Ich würde definitiv argumentieren, dass es einen Fehler im Design gibt, wenn Sie das Gefühl haben, Ausnahmen von einem Property Setter oder Getter auszulösen.
Eine Eigenschaft ist eine Abstraktion, die nur einen Wert darstellt . Und Sie sollten in der Lage sein, einen Wert festzulegen, ohne befürchten zu müssen, dass dies eine Ausnahme auslösen könnte. *
Wenn das Setzen der Eigenschaft zu einem Nebeneffekt führt, sollte dieser eigentlich als Methode implementiert werden. Und wenn es keine Nebenwirkungen erzeugt, sollte keine Ausnahme geworfen werden.
Ein Beispiel, das bereits in einer anderen Antwort erwähnt wurde, ist die Stream.PositionEigenschaft. Dies führt zu Nebenwirkungen und kann Ausnahmen auslösen. Aber dieser Property-Setter ist im Grunde nur ein Wrapper Stream.Seek, den Sie stattdessen aufrufen können.
Persönlich glaube ich, dass die Position keine beschreibbare Eigenschaft sein sollte.
Ein weiteres Beispiel, bei dem Sie versucht sein könnten, eine Ausnahme von einem Eigenschaftssetzer auszulösen, ist die Validierung von Daten:
public class User {
public string Email {
get { return _email; }
set {
if (!IsValidEmail(value)) throw InvalidEmailException(value);
_email = value;
}
}
Aber es gibt eine bessere Lösung für dieses Problem. Geben Sie einen Typ ein, der eine gültige E-Mail-Adresse darstellt:
public class Email {
public Email(string value) {
if (!IsValidEmail(value)) throw new InvalidEmailException(value);
...
}
...
}
public class User {
public Email Email { get; set; }
}
Das Email Klasse stellt sicher, dass kein Wert gespeichert werden kann, der keine gültige E-Mail-Adresse ist, und Klassen, die E-Mails speichern müssen, müssen diese nicht mehr überprüfen.
Dies führt auch zu einer höheren Kohäsion (ein Indikator für gutes Softwaredesign) - das Wissen darüber, was eine E - Mail - Adresse ist und wie sie validiert wird, existiert nur in der Email Klasse, die nur dieses Problem hat.
* ObjectDisposedException ist die einzige gültige Ausnahme (kein Wortspiel beabsichtigt), die mir derzeit einfällt.