Definitivamente, argumentaría que hay un defecto en el diseño si siente la necesidad de lanzar excepciones de un establecedor de propiedades o getter.
Una propiedad es una abstracción que representa algo que es solo un valor . Y debe poder establecer un valor sin temor a que hacerlo pueda generar una excepción. *
Si establecer la propiedad resulta en un efecto secundario, eso debería implementarse realmente como un método. Y si no produce ningún efecto secundario, no se debe lanzar ninguna excepción.
Un ejemplo ya mencionado en una respuesta diferente es la Stream.Positionpropiedad. Esto produce efectos secundarios y puede generar excepciones. Pero este configurador de propiedades es básicamente un envoltorioStream.Seek que podría llamar en su lugar.
Personalmente, creo que el puesto no debería haber sido una propiedad escribible.
Otro ejemplo en el que podría verse tentado a lanzar una excepción desde un configurador de propiedades es en la validación de datos:
public class User {
public string Email {
get { return _email; }
set {
if (!IsValidEmail(value)) throw InvalidEmailException(value);
_email = value;
}
}
Pero hay una mejor solución a este problema. Introduzca un tipo que represente una dirección de correo electrónico válida:
public class Email {
public Email(string value) {
if (!IsValidEmail(value)) throw new InvalidEmailException(value);
...
}
...
}
public class User {
public Email Email { get; set; }
}
los Email clase garantiza que no puede contener un valor que no sea una dirección de correo electrónico válida, y las clases que necesitan almacenar correos electrónicos quedan libres del deber de validarlas.
Esto también conduce a una mayor cohesión (un indicador de un buen diseño de software): el conocimiento sobre qué es una dirección de correo electrónico y cómo se valida solo existe en el Email clase, que solo tiene esa preocupación.
* ObjectDisposedException es la única excepción válida (sin juego de palabras) que se me ocurre en este momento.